draft-ietf-dnsext-rfc2672bis-dname-07.txt   draft-ietf-dnsext-rfc2672bis-dname-08.txt 
DNS Extensions Working Group S. Rose DNS Extensions Working Group S. Rose
Internet-Draft NIST Internet-Draft NIST
Updates: 2672,3363,4294 W. Wijngaards Updates: 2672,3363,4294 W. Wijngaards
(if approved) NLnet Labs (if approved) NLnet Labs
Intended status: Standards Track December 13, 2007 Intended status: Standards Track January 14, 2008
Expires: June 15, 2008 Expires: July 17, 2008
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-07 draft-ietf-dnsext-rfc2672bis-dname-08
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 36 skipping to change at page 1, line 36
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 June 15, 2008. This Internet-Draft will expire on July 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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. This is particular suffix are redirected to another part of the DNS. This is
an update to the original specification in RFC 2672, also aligning an update to the original specification in RFC 2672, also aligning
RFC 3363 and RFC 4294 with this revision. RFC 3363 and RFC 4294 with this revision.
Requirements Language Requirements Language
skipping to change at page 2, line 33 skipping to change at page 2, line 33
3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 7 3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 7
3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7 3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7
3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8
4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 10 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 10
5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 11 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 11
5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 11 5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 11
5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 11 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 11
5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 11 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 12
5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 11 5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 12
5.3.2. Validators Must Understand DNAME . . . . . . . . . . . 12 5.3.2. Validators Must Understand DNAME . . . . . . . . . . . 12
5.3.2.1. DNAME in Bitmap Causes Invalid Name Error . . . . 12 5.3.2.1. DNAME in Bitmap Causes Invalid Name Error . . . . 12
5.3.2.2. Valid Name Error Response Involving DNAME in 5.3.2.2. Valid Name Error Response Involving DNAME in
Bitmap . . . . . . . . . . . . . . . . . . . . . . 12 Bitmap . . . . . . . . . . . . . . . . . . . . . . 12
5.3.2.3. Response With Synthesized CNAME . . . . . . . . . 12 5.3.2.3. Response With Synthesized CNAME . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
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.
skipping to change at page 5, line 38 skipping to change at page 5, line 38
without problem. Then use this DNAME at the zone apex to point without problem. Then use this DNAME at the zone apex to point
queries to the target zone. There still is a need to have the queries to the target zone. There still is a need to have the
customary SOA and NS resource records at the zone apex. This means customary SOA and NS resource records at the zone apex. This means
that DNAME does not mirror a zone completely, as it does not mirror that DNAME does not mirror a zone completely, as it does not mirror
the zone apex. the zone apex.
Another reason for excluding the DNAME owner from the DNAME Another reason for excluding the DNAME owner from the DNAME
substitution is that one can then query for the DNAME through RFC substitution is that one can then query for the DNAME through RFC
1034 [RFC1034] caches. 1034 [RFC1034] caches.
This means that a DNAME RR is not allowed at the same domain name as This means that DNAME RRs are not allowed at the parent side of a
NS records unless there is also a SOA record present. DNAME RRs are delegation point but are allowed at a zone apex.
not allowed at the parent side of a delegation point but are allowed
at a zone apex.
2.4. Names Next to and Below a DNAME Record 2.4. Names Next to and Below a DNAME Record
Other resource records MUST NOT exist below the owner of a DNAME RR. Other resource records MUST NOT exist at a domain name subordinate to
To get the contents for names subordinate to that owner, the DNAME the owner of a DNAME RR. To get the contents for names subordinate
redirection must be invoked and the resulting target queried. A to that owner, the DNAME redirection must be invoked and the
server SHOULD refuse to load a zone that has data below a domain name resulting target queried. A server SHOULD refuse to load a zone that
owning a DNAME RR. Also a server SHOULD refuse to load a zone has data at a domain name subordinate to a domain name owning a DNAME
subordinate to the owner of a DNAME record in the ancestor zone. See RR. Also a server SHOULD refuse to load a zone subordinate to the
Section 5.2 for further restrictions related to dynamic update. owner of a DNAME record in the ancestor zone. See Section 5.2 for
further restrictions related to dynamic update.
DNAME is a singleton type, meaning only one DNAME is allowed per DNAME is a singleton type, meaning only one DNAME is allowed per
name. The owner name of a DNAME can only have one DNAME RR, and no name. The owner name of a DNAME can only have one DNAME RR, and no
CNAME RRs can exist at that name. These rules make sure that for a CNAME RRs can exist at that name. These rules make sure that for a
single domain name only one redirection exists, and thus no confusion single domain name only one redirection exists, and thus no confusion
which one to follow. A server SHOULD refuse to load a zone that which one to follow. A server SHOULD refuse to load a zone that
violates these rules. violates these rules.
The domain name that owns a DNAME record is allowed to have other The domain name that owns a DNAME record is allowed to have other
resource record types at that domain name, except DNAMEs or CNAMEs. resource record types at that domain name, except DNAMEs or CNAMEs.
skipping to change at page 7, line 16 skipping to change at page 7, line 16
On the server side, the DNAME RR record is always included in the On the server side, the DNAME RR record is always included in the
answer section of a query, when one is encountered. A CNAME RR answer section of a query, when one is encountered. A CNAME RR
record with TTL equal to the corresponding DNAME RR is synthesized record with TTL equal to the corresponding DNAME RR is synthesized
for old resolvers, specifically for the QNAME in the query. DNSSEC for old resolvers, specifically for the QNAME in the query. DNSSEC
[RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
not have to be signed. The DNAME has an RRSIG and a validating not have to be signed. The DNAME has an RRSIG and a validating
resolver can check the CNAME against the DNAME record and validate resolver can check the CNAME against the DNAME record and validate
the DNAME record. the DNAME record.
It does not make sense for the authoritative server to follow the
chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
query, as some resolver implementations will remove out-of-zone
information from the answer.
Resolvers MUST be able to handle a synthesized CNAME TTL of zero or Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
equal to the TTL of the corresponding DNAME record. The TTL of zero equal to the TTL of the corresponding DNAME record. The TTL of zero
means that the CNAME can be discarded immediately after processing means that the CNAME can be discarded immediately after processing
the answer. DNAME aware resolvers can set the Understand-DNAME (UD the answer. DNAME aware resolvers can set the Understand-DNAME (UD
bit) to receive a response with only the DNAME RR and no synthesized bit) to receive a response with only the DNAME RR and no synthesized
CNAMEs. CNAMEs.
The UD bit is part of the EDNS extended RCODE and Flags field. It is The UD bit is part of the EDNS extended RCODE and Flags field. It is
used to omit server processing, transmission and resolver processing used to omit server processing, transmission and resolver processing
of unsigned synthesized CNAMEs. Resolvers can set this in a query to of unsigned synthesized CNAMEs. Resolvers can set this in a query to
skipping to change at page 7, line 51 skipping to change at page 7, line 46
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|UD| Z | 2: |DO|UD| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Servers MUST be able to answer a query for a synthesized CNAME. An Servers MUST be able to answer a query for a synthesized CNAME. An
answer containing the synthesized CNAME cannot contain an error answer containing the synthesized CNAME cannot contain an error
(since a CNAME has been followed), as per RFC 1034 CNAME rules. (since a CNAME has been followed), as per RFC 1034 CNAME rules.
3.3. Acceptance and Intermediate Storage 3.3. Acceptance and Intermediate Storage
DNS Caches MUST NOT allow data to be cached below the owner of a DNS caches can encounter data at names below the owner name of a
DNAME RR, except CNAME records and their signatures. CNAME records DNAME RR, due to a change at the authoritative server where data from
below the owner of a DNAME MUST be re-synthesized from the DNAME, or before and after the change resides in the cache. This conflict
checked against the DNAME record before sending them out. This situation is a transitional phase, that ends when the old data times
improves consistency of the DNAME and CNAME records below the owner out. The cache can opt to store both old and new data and treat each
of the DNAME. as if the other did not exist, or drop the old data, or drop the
longer domain name. In any approach, consistency returns after the
older data TTL times out.
DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant
clients. A DNS Cache that understands DNAMEs can send out queries on clients. A DNS Cache that understands DNAMEs can send out queries on
behalf of clients with the UD bit set. After receiving the answers behalf of clients with the UD bit set. After receiving the answers
the DNS Cache sends replies to DNAME ignorant clients that include the DNS Cache sends replies to DNAME ignorant clients that include
DNAMEs and synthesized CNAMEs. DNAMEs and synthesized CNAMEs.
3.4. Server algorithm 3.4. Server algorithm
Below the server algorithm, which appeared in RFC 2672 Section 4.1, Below the server algorithm, which appeared in RFC 2672 Section 4.1,
skipping to change at page 11, line 39 skipping to change at page 11, line 39
involve DNAMEs, the name listed in the PTR record can not fall under 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 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 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 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 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. DNAME substitution already applied to it as the MX, NS, PTR data.
These are valid canonical hostnames. These are valid canonical hostnames.
5.2. Dynamic Update and DNAME 5.2. Dynamic Update and DNAME
Dynamic update for DNAME records works similar to dynamic update for
delegating NS records. For example, adding a DNAME obscures names in
the zone. DNAME records can be added, changed and removed.
Zones containing a DNAME RR MUST NOT accept a dynamic update message Zones containing a DNAME RR MUST NOT accept a dynamic update message
that would add a record or delegation with a name existing under a that would add a record or delegation with a name existing under a
DNAME. DNAME.
A server MUST return an error message with RCODE=REFUSED [RFC2136] in A server MUST return an error message with RCODE=REFUSED [RFC2136] in
response to a dynamic update message that would add a resource record response to a dynamic update message that would add a resource record
under a DNAME in the zone. under a DNAME in the zone.
5.3. DNSSEC and DNAME 5.3. DNSSEC and DNAME
skipping to change at page 13, line 13 skipping to change at page 13, line 13
5.3.2.3. Response With Synthesized CNAME 5.3.2.3. Response With Synthesized CNAME
;; Header: QR AA DO RCODE=0(NOERROR) ;; Header: QR AA DO RCODE=0(NOERROR)
;; Question ;; Question
foo.bar.example.com. IN A foo.bar.example.com. IN A
;; Answer ;; Answer
bar.example.com. DNAME bar.example.net. bar.example.com. DNAME bar.example.net.
bar.example.com. RRSIG DNAME [valid signature] bar.example.com. RRSIG DNAME [valid signature]
foo.bar.example.com. CNAME foo.bar.example.net. foo.bar.example.com. CNAME foo.bar.example.net.
The answer shown above has the synthesized CNAME included. However, The answer shown above has the synthesized CNAME included. However,
the CNAME has no signature, since the server does not sign online (it the CNAME has no signature, since the server does not sign online.
is a slow operation and exposes the signing key). So it cannot be So it cannot be trusted. It could be altered by an attacker to be
trusted. It could be altered by an attacker to be
foo.bar.example.com CNAME bla.bla.example. The DNAME record does foo.bar.example.com CNAME bla.bla.example. The DNAME record does
have its signature included, since it does not change for every query have its signature included, since it does not change for every query
name. The validator must verify the DNAME signature and then name. The validator must verify the DNAME signature and then
recursively resolve further to query for the foo.bar.example.net A recursively resolve further to query for the foo.bar.example.net A
record. record.
6. IANA Considerations 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 original document registered the use of DNAME RRs in a DNS zone. The original document registered the
skipping to change at page 16, line 7 skipping to change at page 16, line 7
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
EMail: wouter@nlnetlabs.nl EMail: wouter@nlnetlabs.nl
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 13 change blocks. 
34 lines changed or deleted 33 lines changed or added

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