draft-ietf-dnsext-rfc2672bis-dname-00.txt   draft-ietf-dnsext-rfc2672bis-dname-01.txt 
DNS Extensions Working Group S. Rose DNS Extensions Working Group S. Rose
Internet-Draft VeriSign, Inc. Internet-Draft NIST
Intended status: Standards Track W. Wijngaards Intended status: Standards Track W. Wijngaards
Expires: March 29, 2007 NLnet Labs Expires: July 26, 2007 NLnet Labs
September 25, 2006 January 22, 2007
Update to DNAME Redirection Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-00 draft-ietf-dnsext-rfc2672bis-dname-01
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 29, 2007. This Internet-Draft will expire on July 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The DNAME record provides redirection for a sub-tree of the domain The DNAME record provides redirection for a sub-tree of the domain
name tree in the DNS system. That is, all names that end with a name tree in the DNS system. That is, all names that end with a
particular suffix are redirected to another part of the DNS. Changes particular suffix are redirected to another part of the DNS. This is
to the DNS protocol since DNAME's introduction has lead to a need to an update to the original specification in RFC 2672.
clarify several issues in the DNAME specification. These issues are
discussed in this document. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . . 3 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3
2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4
2.3. Names next-to and below a DNAME record . . . . . . . . . . 5
2.4. Compression of the DNAME record. . . . . . . . . . . . . . 5
3. DNAME according to RFC 2672 . . . . . . . . . . . . . . . . . . 4 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. A DNAME in a Zone . . . . . . . . . . . . . . . . . . . . . 4 3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. DNAME in Responses . . . . . . . . . . . . . . . . . . . . 4 3.2. DNAME bit in NSEC type map . . . . . . . . . . . . . . . . 6
3.3. DNAME Discussions in Other Documents . . . . . . . . . . . 5 3.3. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 6
3.4. Processing . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Issues with DNAME . . . . . . . . . . . . . . . . . . . . . . . 5 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 7
4.1. DNAME as Delegation Tool . . . . . . . . . . . . . . . . . 5
4.2. DNAME Apex is not Redirected Itself . . . . . . . . . . . . 5
4.3. DNAME is Always Included in Outgoing Packets. . . . . . . . 6
4.4. MX and NS Records Require that the DNAME in their
RDATA is Canonical . . . . . . . . . . . . . . . . . . . . 6
4.5. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Signaling of DNAME Understanding . . . . . . . . . . . . . 6
4.7. A DNAME is not a Zone-cut . . . . . . . . . . . . . . . . . 6
4.8. DNAME and CIDR Blocks in in-addr.arpa . . . . . . . . . . . 6
4.9. Name Compression in RDATA . . . . . . . . . . . . . . . . . 6
4.10. Synthesized CNAME TTL=0 . . . . . . . . . . . . . . . . . . 7
4.11. Wildcarded DNAME . . . . . . . . . . . . . . . . . . . . . 7
4.12. NSEC3 and DNAME . . . . . . . . . . . . . . . . . . . . . . 7
4.13. PTR Records and DNAME . . . . . . . . . . . . . . . . . . . 7
4.14. Small Corner Cases . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 5. Issues with DNAME . . . . . . . . . . . . . . . . . . . . . . 7
5.1. DNAME Apex not Redirected itself . . . . . . . . . . . . . 8
5.2. MX, NS and PTR Records Must Point to Target of DNAME . . . 8
5.3. NSEC3 and DNAME . . . . . . . . . . . . . . . . . . . . . 8
5.4. Validators Must Understand DNAME . . . . . . . . . . . . . 9
5.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . . . 9
5.4.2. Valid Name Error Response Involving DNAME in Bitmap . 9
5.4.3. Response With Synthesized CNAME . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. Normative References . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
DNAME is a DNS Resource Record type. DNAME provides redirection from DNAME is a DNS Resource Record type. DNAME provides redirection from
a part of the DNS name tree to another part of the DNS name tree. a part of the DNS name tree to another part of the DNS name tree.
For example, given a query for foo.example.com and a DNAME from For example, given a query for foo.example.com and a DNAME from
example.com to example.net, the query would be redirected to example.com to example.net, the query would be redirected to
foo.example.net. With the same DNAME a query for foo.bar.example.com foo.example.net. With the same DNAME a query for foo.bar.example.com
is redirected to foo.bar.example.net. is redirected to foo.bar.example.net.
The DNAME RR is similar to the CNAME RR in that it provides The DNAME RR is similar to the CNAME RR in that it provides
redirection. But where the CNAME RR only provides redirection for redirection. But where the CNAME RR only provides redirection for
exactly one name, the DNAME RR provides redirection for all names in exactly one name, the DNAME RR provides redirection for all names in
a sub-tree of the DNS name tree. a sub-tree of the DNS name tree.
The usage of DNAME lies in redirection of name spaces. An important This document is an update to the original specification of DNAME in
use is finer control over delegation, where you want several names to RFC 2672 [RFC2672], by Matt Crawford. DNAME was conceived to help
be directed to the same name server. In other words, you would like with the problem of maintaining address-to-name mappings in a context
the name spaces below several names to be mapped to the same zone. of network renumbering. So that with a careful set-up a renumbering
Examples in practice are classless reverse address space delegations event in the network causes no change to the authoritative server
and punycode alternates for domain spaces. All the usage examples that has the address-to-name mappings.
envisioned are really for the delegation of multiple different names
below a zone to the same sub-zone, even though the DNAME syntax
permits more bizarre redirection patterns.
[[editors note: In this version of the draft, issues that have been Other usage of DNAME lies in redirection of name spaces. Where a
identified are discussed, and some ideas for proposals are put zone administrator want subtrees of the DNS to contain the same
forward. Later versions of this document will contain more formal information. Examples in practice are classless reverse address
clarifications or an update to the DNAME specification.]] space delegations and punycode alternates for domain spaces. DNAME
is also used for redirection of ENUM domains to another maintaining
party.
This update to DNAME does not change the wire format, or the handling
of DNAME Resource Records by existing software. Discussion is added
on the problems that can be encountered when using DNAME.
2. The DNAME Resource Record 2. The DNAME Resource Record
2.1. Format
The DNAME RR has mnemonic DNAME and type code 39 (decimal). The DNAME RR has mnemonic DNAME and type code 39 (decimal).
The format of the DNAME record has not changed compared to RFC 2672. The format of the DNAME record has not changed compared to RFC 2672.
DNAME has the following format: DNAME has the following format:
<owner> <ttl> <class> DNAME <target> <owner> <ttl> <class> DNAME <target>
The format is not class-sensitive. All fields are required. The The format is not class-sensitive. All fields are required. The
RDATA field target is a domain-name. The compression of the RDATA RDATA field target is a domain-name. The RDATA field target name
field target name issue is covered in a later section. MUST be sent uncompressed [RFC3597].
The DNAME RR causes type NS additional section processing. The DNAME RR causes type NS additional section processing.
DNAME is a singleton type, only one DNAME is allowed per name. No 2.2. The DNAME Substitution
resource records exist below a DNAME.
CNAME and DNAME are not allowed together for the same name. This is DNAMEs cause a name substitution to happen to query names. This is
because no records are allowed next to a CNAME. called The DNAME Substitution. The suffix ownername of the DNAME is
replaced by the target of the DNAME. The owner name of the DNAME is
not itself redirected, only domain names below the owner name are
redirected. Only whole labels are replaced. A name is considered
below the owner name if it has more labels than the owner name, and
the labels of the owner name appear at the end of the name. See the
table of examples for common cases and corner cases.
DNAMEs cause substitution to happen to query names. There are limits In the table below, the QNAME refers to the query name. The owner is
on the descendants of a name with a DNAME record (none allowed), and the DNAME owner domain name, and the target refers to the target of
limits on record types allowed for the name that has the DNAME, as the DNAME record. The result is the resulting name of performing the
well as loops that are possible due to DNAMEs. These issues are DNAME Substitution on the query name. "no match" means that the query
explained more thoroughly in later sections. did not match the DNAME and thus no substitution is performed, the
QNAME did not change. The examples 'cyc' and 'shortloop' contain
loops.
3. DNAME according to RFC 2672 QNAME owner DNAME target result
---------------- -------------- -------------- -----------------
com. example.com. example.net. <no match>
example.com. example.com. example.net. <no match>
a.example.com. example.com. example.net. a.example.net.
a.b.example.com. example.com. example.net. a.b.example.net.
ab.example.com. b.example.com. example.net. <no match>
foo.example.com. example.com. example.net. foo.example.net.
a.x.example.com. x.example.com. example.net. a.example.net.
a.example.com. example.com. y.example.net. a.y.example.net.
cyc.example.com. example.com. example.com. cyc.example.com.
cyc.example.com. example.com. c.example.com. cyc.c.example.com.
shortloop.x.x. x. . shortloop.x.
shortloop.x. x. . shortloop.
This section presents a clarification of what RFC 2672 says. Table. DNAME Substitution Examples.
3.1. A DNAME in a Zone It is possible for DNAMEs to form loops. Just like CNAMEs can form
loops. DNAMEs and CNAMEs can chain together to form loops. A single
corner case DNAME can form a loop. Resolvers and servers should be
cautious in devoting resources to a query, but be aware that fairly
long chains of DNAMEs may be valid.
x. DNAME y. is like having CNAMEs for all records with domain names The domain name can get too long during substitution. If this occurs
ending in .x to domain names ending in .y. The DNAME RR only impacts the server returns an RCODE of YXDOMAIN [RFC2136]. The DNAME record
labels below x., such as foo.x., foo.bar.x., but not x. itself. The and its signature are included in the answer as proof for the
DNAME RR allows RRs of other types to be at x with the exception of YXDOMAIN (value 6) RCODE.
RRType CNAME. The DNAME RR above does not allow a CNAME or other
DNAME RRs at x. So a DNAME RRset may only have one RR in it, and
CNAMEs and DNAMEs are mutually exclusive. DNAMEs are valid only for
their CLASS. For a different CLASS different DNAME records are
allowed.
x. DNAME y. does not allow anything to exist below x. Thus, foo.x., 2.3. Names next-to and below a DNAME record
foo.bar.x are not allowed to have RRs. Their contents are hidden and
ignored. To get their contents the DNAME must be invoked and the
resulting target queried.
3.2. DNAME in Responses Other resource records MUST NOT exist below a DNAME. To get the
contents for names below a DNAME, the DNAME redirection must be
invoked and the resulting target queried. A server SHOULD refuse to
load a zone that has data below a domain with a DNAME resource
record. Also a server SHOULD refuse to load a zone beneath a DNAME
record from another zone.
The DNAME RR record is always included in the answer section of a DNAME is a singleton type, only one DNAME is allowed per name. The
query. The target name of the DNAME (y.) is to be sent uncompressed owner name that has a DNAME, can only have one DNAME RR, and no CNAME
to old resolvers (so the DNAME can be treated as an unknown type). RRs can exist at that name. These rules make sure that for a single
Compressed if possible. Thus servers must be able to read compressed domain name only one redirection exists, and thus no confusion which
or uncompressed target names and write uncompressed names for old one to follow. A server SHOULD refuse to load a zone that violates
resolvers. See issue on target RDATA compression. these rules.
A CNAME RR record with TTL 0 is synthesized for old resolvers, These rules allow DNAME records to be queried through DNAME unaware
specifically for the QNAME in the query. DNSSEC [RFC4033], caches.
[RFC4034], [RFC4035] says that the synthesized CNAMEs do not have to
be signed. The DNAME has an RRSIG and a validating resolver can
check the CNAMEs against the DNAME record.
RFC2672 claims that EDNS 0 and less signals non-understanding of 2.4. Compression of the DNAME record.
DNAME and DNAME target name compression. EDNS 1 and up may signal
understanding. The EDNS DNSSEC-OK bit signals understanding of
DNAME.
3.3. DNAME Discussions in Other Documents The DNAME owner name can be compressed like any other owner name.
The target DNAME RDATA name of MUST NOT be sent out in compressed
form, so that DNAME can be treated as an unknown type.
In [RFC2181] as reference, in Section 10.3., some information is Although the previous specification talked about signaling to allow
pertinent, on MX and NS records.: compression of the target name, no such signaling is done. Signaling
complicates the protocol unnecessarily.
10.3. MX and NS records (in RFC 2181) RFC2672 claimed that the EDNS version had a meaning for understanding
of DNAME and DNAME target name compression. This document updates
RFC2672, there is no EDNS version signaling for DNAME.
The domain name used as the value of a NS resource record, or part of 3. Processing
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
RFC 4592 [RFC4592] says that DNAMEs are discouraged at wildcards. 3.1. Wildcards
DNAMEs and CNAMEs can form loops.
DNAME is discussed in RFC 3363, section 4, on A6 and DNAME. DNAME is The use of DNAME in conjunction with wildcards is discouraged
NOT RECOMMENDED for use in the ip6 reverse tree [RFC3363]. And from [RFC4592]. Thus records of the form "*.example.com DNAME
[RFC4294], all references to DNAME should have been removed. There example.net" SHOULD NOT be used.
needs to be a better clarification of the status of DNAME in RFC 3363
which would be to drop all constraints on having DNAME RRs in these
zones.
4. Issues with DNAME The interaction between the expansion of the wildcard and the
redirection of the DNAME is non-deterministic. Because the
processing is non-deterministic, DNSSEC validating resolvers may not
be able to validate a wildcarded DNAME.
There are several issues on DNAME as specified in RFC 2672 [RFC2672]. A server MAY give a warning that the behaviour is unspecified if such
a wildcarded DNAME is loaded.
4.1. DNAME as Delegation Tool 3.2. DNAME bit in NSEC type map
DNAMEs can be used as indirections, the goal of these indirections is When a validator checks the NSEC RRs returned on a name error
to mirror a part of the DNS domain tree in another part of the DNS response, it SHOULD check that the DNAME bit is not set. If the
domain tree. This mirroring should be easy. Alternative wording is DNAME bit is set then the DNAME substitution should have been done,
that the goal is to have an alias name for a part of the domain tree. but has not. In the same vein, for a no error/no data response the
Running example is x DNAME y. The extra point here is that the CNAME bit in the NSEC RR bitmap should not be set.
mirroring is done at exactly a delegation point. There is a use for
this case.
4.2. DNAME Apex is not Redirected Itself 3.3. CNAME synthesis
Since the x is not CNAME'd itself, queries for the DNAME apex RRs are On the server side, the DNAME RR record is always included in the
answered with data at x not at y. The reason for the original answer section of a query. A CNAME RR record with TTL 0 is
decision was that in this way (without DNAME apex affected) one can synthesized for old resolvers, specifically for the QNAME in the
have a DNAME at the zone apex, next to the SOA, NS records, without query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the
problem. And use this to point zones under your operational control synthesized CNAME does not have to be signed. The DNAME has an RRSIG
to other zones. Hosting two identical zones for example. Another and a validating resolver can check the CNAME against the DNAME
reason for excluding the DNAME apex from the DNAME is that one can record and validate the DNAME record.
then query for the DNAME through RFC 1034 [RFC1034] caches.
4.3. DNAME is Always Included in Outgoing Packets. The TTL of the synthesized CNAME record MAY be set to the TTL of the
DNAME record. This enables older caches store the CNAMEs without a
need to re-query for them. This updates RFC2672 which stated the TTL
had to be zero.
Old resolvers or firewalls may drop packets with this unknown RR It does not make sense for the authoritative server to follow the
type. chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
query, as modern resolvers will remove out-of-zone information from
the answer.
4.4. MX and NS Records Require that the DNAME in their RDATA is The EDNS DNSSEC-OK bit signals understanding of the DNAME record
Canonical [RFC4034]. If set, the synthesized CNAME MAY be omitted, since it is
not signed and therefore not useful for validation and a waste of
bandwidth. This is a change from RFC2672, which specified CNAMEs had
to be synthesized for all EDNS0, or non-extended queries.
This means immediately resolve, no CNAMEs no DNAMEs. See the Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
reference to RFC 2181, Section 10.3 above. Also in RFC 1912 equal to the TTL of the corresponding DNAME record. The TTL of zero
[RFC1912], Section 2.4. means that the CNAME can be discarded immediately after processing
the answer.
4.5. DNSSEC Servers MUST be able to answer a query for a synthesized CNAME. An
answer containing the synthesized CNAME cannot contain an error
(since a CNAME has been followed), as per RFC 1034 CNAME rules.
For a name error response, the resolver has to check the closest 3.4. Processing
encloser NSEC to make sure it has no DNAME bit set. If a DNAME had
been present, that DNAME redirection should have been followed.
4.6. Signaling of DNAME Understanding TBD: An issue with some firewalls and middleboxes, and perhaps
windows XP/2003 resolvers potentially responding badly to DNAME
records (dropping packets),
TBD: Is this useful to specify? Resolvers MUST be able to handle
unsigned responses with only the CNAME, or with the DNAME only, or
both CNAME and DNAME. Resolvers that query with DNSSEC_OK MUST be
able to handle signed responses with only the DNAME, or with the
unsigned synthesized CNAME included.
Some mechanism to signal that CNAMEs need not be synthesized. Also Caches MUST NOT allow data to be cached below a DNAME. Except CNAME
signal that DNAME target compression can be used (if RDATA target records or perhaps NSEC3 records and their signatures. CNAME records
name compression is allowed at all). EDNS version seems the most below a DNAME MUST be re-synthesized from the DNAME, or checked
obvious, states the rfc. The gain is compression of the DNAME rname, against the DNAME record before sending them out. This improves
and smaller response size. consistency of the DNAME and CNAME records below it.
4.7. A DNAME is not a Zone-cut 4. DNAME Discussions in Other Documents
A DNAME is not a zone-cut. You may want to use it as such to mirror In [RFC2181], in Section 10.3., the discussion on MX and NS records
a part of the DNS tree, but RFC 2672 DNAME is not usable because the touches on redirection by CNAMEs, but this also holds for DNAMEs.
apex is not redirected.
4.8. DNAME and CIDR Blocks in in-addr.arpa Excerpt from 10.3. MX and NS records (in RFC 2181).
Is DNAME the Way to go for CIDR Blocks in in-addr.arpa? Should this The domain name used as the value of a NS resource record,
be addressed by this document? or part of the value of a MX resource record must not be
an alias. Not only is the specification clear on this
point, but using an alias in either of these positions
neither works as well as might be hoped, nor well fulfills
the ambition that may have led to this approach. This
domain name must have as its value one or more address
records. Currently those will be A records, however in
the future other record types giving addressing
information may be acceptable. It can also have other
RRs, but never a CNAME RR.
4.9. Name Compression in RDATA RFC 4592 [RFC4592] says that DNAMEs are discouraged at wildcards.
DNAMEs and CNAMEs can form loops.
For old versions of servers only uncompressed is possible. New DNAME is discussed in RFC 3363, section 4, on A6 and DNAME. DNAME is
version can still choose to use compressed or not. NOT RECOMMENDED for use in the IPv66 reverse tree [RFC3363]. And
from [RFC4294], all references to DNAME should have been removed.
There needs to be a better clarification of the status of DNAME in
RFC 3363 which would be to drop all constraints on having DNAME RRs
in these zones.
Clarify on compression proposal: Senders SHOULD NOT compress RDATA, 5. Issues with DNAME
receivers MUST be able to decompress, when the new version has been
negotiated with the EDNS bits.
4.10. Synthesized CNAME TTL=0 There are several issues to be aware of about the use of DNAME.
In the original specification, all synthesized CNAME RRs had a TTL of 5.1. DNAME Apex not Redirected itself
0. Due to DNSSEC TTL=0 interpretation had to be changed to mean
"keep as long as the query using this RRset is still being
processed". What is the status of this CNAME?
This could be synthesized CNAMEs should have a TTL equal to the TTL The owner name of a DNAME is not redirected itself. The reason for
of the DNAME. This allows non-aware clients to cache the CNAMEs and the original decision was that in this way (without DNAME owner
thus lightens the load on authoritative servers. affected) one can have a DNAME at the zone apex, next to the SOA, NS
records, without problem. Then use this to point queries to this
zone to other zones. Hosting two identical zones for example, there
still is a need to duplicate the resource records at the zone apex.
Another reason for excluding the DNAME owner from the DNAME
substitution is that one can then query for the DNAME through RFC
1034 [RFC1034] caches.
4.11. Wildcarded DNAME This means that DNAME does not mirror a zone completely, as it does
not mirror the zone apex. It can be used if the zone apex records
are duplicated to provide a summary of the rest of the zone.
What should happen with a wildcard with RRtype DNAME, i.e. The rules on DNAME RRs mean that it is not allowed at the same domain
*.example.com DNAME example.net. RFC 4592 [RFC4592] discourages name as NS records unless there is also a SOA record there. This
this. Behaviour unspecified (strict interpretation of RFC 2672 says means DNAME RRs are not allowed at the parent side of a delegation
that for queries for which the wildcard is expanded, no DNAME point. DNAME is allowed at a zone apex.
processing occurs, and for queries for the '*' label
('foo.*.example.com') the DNAME is followed.).
4.12. NSEC3 and DNAME 5.2. MX, NS and PTR Records Must Point to Target of DNAME
NSEC3 uses hashing to obscure names. This hashing can be expensive The names listed as target names of MX, NS and PTR records must be
to compute. A zone that has DNAME and NSEC3 may have to do canonical hostnames. This means no CNAME or DNAME redirection may be
additional hashing for NSEC3 lookups. More work needs to be done to present during DNS lookup of the address records for the host. This
look into this and see what computational costs are involved. is discussed in RFC 2181 [RFC2181], section 10.3, and RFC 1912
[RFC1912], section 2.4.
4.13. PTR Records and DNAME The upshot of this is that although the lookup of a PTR record can
involve DNAMEs, the name listed in the PTR record can not fall under
a DNAME. The same holds for NS and MX records. For example, when
punycode alternates for a zone use DNAME then the NS, MX and PTR
records that point to that zone must use names without punycode in
their RDATA. What must be done then is to have the domain names with
DNAME substitution already applied to it as the MX, NS, PTR data.
These are valid canonical hostnames.
PTR records in the reverse zone must have canonical names as their 5.3. NSEC3 and DNAME
RDATA, like NS and MX records. The lookup process for PTR records
owner names may involve DNAME/CNAME records, but the lookup process
for PTR records RDATA names may not. RFC 1912. More problematic
than NS and MX in operational sense, since the reverse zone may not
be under the control of the zone operator.
4.14. Small Corner Cases NSEC3 records and their signatures are allowed to exist below a
DNAME. This is because of the nature of NSEC3 RRs in DNSSEC, which
creates hashed owner names that exist below the apex. This is an
exception to the rule that there MUST NOT be any other RRs under a
DNAME RR, if the DNAME RR exists at the zone apex.
There are also some corner cases to discuss and clarify. These are TBD: This is a new issue, but the same as the NSEC3 draft.
small issues, but additional examples can give more guidance to
implementors. [[editors note: The following is to be expanded]]
1. Example of why DNSSEC validators MUST understand DNAME.
2. Examples of the DNAME name substitution. whole labels only, name
can get longer and shorter. The '*' label is handled as a fixed
string during substitution. apex is not substituted. name can get
too long.
3. Corner case: queries for synthesized CNAME. Not a problem,
current algorithm already creates the CNAME again from the DNAME
for such a query and follows the chain of DNAME/CNAMEs. Server
reminded that it must return no error.
4. Corner case: loops with single DNAME record possible. Loop: x
DNAME y.x. Loop: x DNAME x. Loop: x DNAME "." for queries
qname=a.x.x
5. Servers must not allow zones to be loaded below a DNAME. This is
similar to requesting to not load a zone when a domain name below
a DNAME contains resource records, as the RFC requests.
6. Caches must not allow data to be cached below a DNAME. CNAMES
below a DNAME must be re-synthesized from the DNAME, or checked
against the DNAME if needed.
5. IANA Considerations Queries for NSEC3 owner names are redirected as if there were no such
NSEC3 present.
There is no significant extra hashing cost for NSEC3 signed zones
when answering queries with DNAME substitution.
5.4. Validators Must Understand DNAME
Examples of why DNSSEC validators MUST understand DNAME.
5.4.1. DNAME in Bitmap Causes Invalid Name Error
;; Header: QR AA DO RCODE=3(NXDOMAIN)
;; Question
foo.bar.example.com. IN A
;; Answer
bar.example.com. NSEC dub.example.com. A DNAME
bar.example.com. RRSIG NSEC [valid signature]
If you receive this answer, then only by understanding that the DNAME
bit means that foo.bar.example.com needed to have been redirected by
the DNAME, the validator can see that it is a BOGUS reply from an
attacker, that collated existing records from the DNS to create a
confusing reply.
If the DNAME bit had not been set in the NSEC record above, then the
answer would have validated as a correct name error response.
5.4.2. Valid Name Error Response Involving DNAME in Bitmap
;; Header: QR AA DO RCODE=3(NXDOMAIN)
;; Question
cee.example.com. IN A
;; Answer
bar.example.com. NSEC dub.example.com. A DNAME
bar.example.com. RRSIG NSEC [valid signature]
If the query had been cee.example.com as shown above, then this
answer would have been validated, because 'cee' does not get
redirected by the DNAME at 'bar'.
5.4.3. Response With Synthesized CNAME
;; Header: QR AA DO RCODE=0(NOERROR)
;; Question
foo.bar.example.com. IN A
;; Answer
bar.example.com. DNAME bar.example.net.
bar.example.com. RRSIG DNAME [valid signature]
foo.bar.example.com. CNAME foo.bar.example.net.
The answer shown above has the synthesized CNAME included. However,
the CNAME has no signature, since the server cannot sign the keys
online (it is a slow operation and exposes the signing key). So it
cannot be trusted. It could be altered by an attacker to be
foo.bar.example.com CNAME bla.bla.example. The DNAME record does
have its signature included, since it does not change for every query
name. The validator must verify the DNAME signature and then
recursively resolve further to query for the foo.bar.example.net A
record.
6. IANA Considerations
The main purpose of this draft is to discuss issues related to the The main purpose of this draft is to discuss issues related to the
use of DNAME RRs in a DNS zone. The results of these discussions may use of DNAME RRs in a DNS zone. The original document registered the
result in a new RR to augment or replace DNAME, which will require DNAME Resource Record type code 39 (decimal). No further action is
IANA action. Any solutions that propose this will be contained in a required on the part of IANA.
following document and not this draft.
6. Security Considerations 7. Security Considerations
DNAME redirects queries elsewhere, which may impact security based on DNAME redirects queries elsewhere, which may impact security based on
policy and the security status of the zone with the DNAME and the policy and the security status of the zone with the DNAME and the
redirection zone's security status. This document only discusses redirection zone's security status.
issues regarding the DNAME specification. Any clarification or
replacement RR type will have different security considerations.
These will be stated in a following document.
7. Acknowledgements If a validating resolver accepts wildcarded DNAMEs, this creates
security issues. Since the processing of a wildcarded DNAME is non-
deterministic and the CNAME that was substituted by the server has no
signature, the resolver may choose a different result than what the
server meant, and consequently end up at the wrong destination. Use
of wildcarded DNAMEs is discouraged in any case [RFC4592].
A validating resolver MUST understand DNAME, according to [RFC4034].
In Section 5.4 examples are given that illustrate this need. These
examples are shown with NSEC records, but similar cases exist for
NSEC3.
8. Document History
00-01. Small language issues. Removed wording of 'delegation' for
dname use to alias a whole zone from parent side (registration tool).
Names under a DNAME are not canonical. Synthesized CNAME is not
signed. Rewritten entirely as an update to the rfc.
9. Acknowledgments
The authors of this draft would like to acknowledge Matt Larson for The authors of this draft would like to acknowledge Matt Larson for
beginning this effort to addres the issues related to the DNAME RR beginning this effort to address the issues related to the DNAME RR
type. type.
8. Normative References 10. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1912] Barr, D., "Common DNS Operational and Configuration [RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, February 1996. Errors", RFC 1912, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999. RFC 2672, August 1999.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363, Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002. August 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
skipping to change at page 9, line 38 skipping to change at page 12, line 14
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006. April 2006.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006. System", RFC 4592, July 2006.
Authors' Addresses Authors' Addresses
Scott Rose Scott Rose
VeriSign, Inc. NIST
21345 Ridgetop Circle 100 Bureau Dr.
Dulles, VA 20166-6503 Gaithersburg, MD 20899
USA USA
Phone: +1-703-948-3364 Phone: +1-301-975-8439
Fax: +1-... Fax: +1-301-975-6238
EMail: srose@verisign.com EMail: scottr@nist.gov
Wouter Wijngaards Wouter Wijngaards
NLnet Labs NLnet Labs
Kruislaan 419 Kruislaan 419
Amsterdam 1098 VA Amsterdam 1098 VA
The Netherlands The Netherlands
Phone: +31-20-888-4551 Phone: +31-20-888-4551
Fax: +31-20-888-4462 Fax: +31-20-888-4462
EMail: wouter@nlnetlabs.nl EMail: wouter@nlnetlabs.nl
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 80 change blocks. 
236 lines changed or deleted 358 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/