draft-ietf-dnsext-rfc2672bis-dname-03.txt   draft-ietf-dnsext-rfc2672bis-dname-04.txt 
DNS Extensions Working Group S. Rose DNS Extensions Working Group S. Rose
Internet-Draft NIST Internet-Draft NIST
Intended status: Standards Track W. Wijngaards Intended status: Standards Track W. Wijngaards
Expires: December 6, 2007 NLnet Labs Expires: February 11, 2008 NLnet Labs
June 4, 2007 August 10, 2007
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-03 draft-ietf-dnsext-rfc2672bis-dname-04
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 December 6, 2007. This Internet-Draft will expire on February 11, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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. This is particular suffix are redirected to another part of the DNS. This is
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 6 3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 6
3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7 3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7
3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 7 3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 7
4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 9 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 9
5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 10 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 11
5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 10 5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 11
5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 10 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 11
5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 10 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. DNAME bit in NSEC/NSEC3 type map . . . . . . . . . . . 10 5.3.1. DNAME bit in NSEC/NSEC3 type map . . . . . . . . . . . 11
5.3.2. Other issues with NSEC3 and DNAME . . . . . . . . . . 11 5.3.2. Other issues with NSEC3 and DNAME . . . . . . . . . . 12
5.3.3. Validators Must Understand DNAME . . . . . . . . . . . 11 5.3.3. Validators Must Understand DNAME . . . . . . . . . . . 12
5.3.3.1. DNAME in Bitmap Causes Invalid Name Error . . . . 11 5.3.3.1. DNAME in Bitmap Causes Invalid Name Error . . . . 12
5.3.3.2. Valid Name Error Response Involving DNAME in 5.3.3.2. Valid Name Error Response Involving DNAME in
Bitmap . . . . . . . . . . . . . . . . . . . . . . 11 Bitmap . . . . . . . . . . . . . . . . . . . . . . 12
5.3.3.3. Response With Synthesized CNAME . . . . . . . . . 12 5.3.3.3. Response With Synthesized CNAME . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
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
would be redirected to foo.bar.example.net. would be redirected to foo.bar.example.net.
skipping to change at page 3, line 33 skipping to change at page 3, line 33
renumbering. So that with a careful set-up a renumbering event in renumbering. So that with a careful set-up a renumbering event in
the network causes no change to the authoritative server that has the the network causes no change to the authoritative server that has the
address-to-name mappings. Examples in practice are classless reverse address-to-name mappings. Examples in practice are classless reverse
address space delegations and punycode alternates for domain spaces. address space delegations and punycode alternates for domain spaces.
Other usage of DNAME lies in redirection of name spaces. For Other usage of DNAME lies in redirection of name spaces. For
example, a zone administrator may want subtrees of the DNS to contain example, a zone administrator may want subtrees of the DNS to contain
the same information. DNAME is also used for redirection of ENUM the same information. DNAME is also used for redirection of ENUM
domains to another maintaining party. domains to another maintaining party.
This update to DNAME does not change the wire format or the server This update to DNAME does not change the wire format or the handling
processing of DNAME Resource Records. Resolvers now have to be able of DNAME Resource Records by existing software. A new UD (Understand
to accept synthesized CNAME records both with zero and nonzero TTLs, Dname) bit in the EDNS flags field can be used to signal that CNAME
and resolvers now have to accept a reply without synthesized CNAME synthesis is not needed. Discussion is added on problems that may be
records on queries with DO-bit enabled. Discussion is added on encountered when using DNAME.
problems that may be encountered when using DNAME.
2. The DNAME Resource Record 2. The DNAME Resource Record
2.1. Format 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 from the original The format of the DNAME record has not changed from the original
specification in RFC 2672. DNAME has the following format: specification in RFC 2672. DNAME has the following format:
skipping to change at page 6, line 19 skipping to change at page 6, line 18
The DNAME RDATA target name MUST NOT be sent out in compressed form, The DNAME RDATA target name MUST NOT be sent out in compressed form,
so that a DNAME RR can be treated as an unknown type. so that a DNAME RR can be treated as an unknown type.
Although the previous specification [RFC2672] talked about signaling Although the previous specification [RFC2672] talked about signaling
to allow compression of the target name, no such signaling is to allow compression of the target name, no such signaling is
explicitly specified. explicitly specified.
RFC2672 stated that the EDNS version had a meaning for understanding RFC2672 stated that the EDNS version had a meaning for understanding
of DNAME and DNAME target name compression. This document updates of DNAME and DNAME target name compression. This document updates
RFC2672, in that there is no EDNS version signaling for DNAME as of RFC2672, in that there is no EDNS version signaling for DNAME as of
yet. yet. However, the flags section of EDNS(0) is updated with a
Understand-DNAME flag by this document (See Section 3.2).
3. Processing 3. Processing
3.1. Wildcards 3.1. Wildcards
The use of DNAME in conjunction with wildcards is discouraged The use of DNAME in conjunction with wildcards is discouraged
[RFC4592]. Thus records of the form "*.example.com DNAME [RFC4592]. Thus records of the form "*.example.com DNAME
example.net" SHOULD NOT be used. example.net" SHOULD NOT be used.
The interaction between the expansion of the wildcard and the The interaction between the expansion of the wildcard and the
skipping to change at page 7, line 8 skipping to change at page 7, line 6
record and validate the DNAME record. record and validate the DNAME record.
It does not make sense for the authoritative server to follow the It does not make sense for the authoritative server to follow the
chain of DNAMEs, CNAMEs and wildcards outside of the zone of the chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
query, as modern resolvers will remove out-of-zone information from query, as modern resolvers will remove out-of-zone information from
the answer. 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. DNSSEC aware resolvers (setting the DNSSEC-OK bit) MUST the answer. DNSSEC aware resolvers can set the Understand-DNAME (UD
be able to handle responses 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
used to omit server processing, transmission and resolver processing
the unsigned synthesized CNAMEs when DNSSEC validation is performed.
Resolvers can set this in a query to request omission of the
synthesized CNAMEs. Servers copy the UD bit to the response, and can
omit synthesized CNAMEs from the answer. Older resolvers do not set
the UD bit, and older servers do not copy the UD bit to the answer,
and will not omit synthesized CNAMEs.
Updated EDNS extended RCODE and Flags field.
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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 MUST NOT allow data to be cached below the owner of a
DNAME RR, except CNAME records or perhaps NSEC3 records and their DNAME RR, except CNAME records or perhaps NSEC3 records and their
signatures. CNAME records below the owner of a DNAME MUST be re- signatures. CNAME records below the owner of a DNAME MUST be re-
synthesized from the DNAME, or checked against the DNAME record synthesized from the DNAME, or checked against the DNAME record
before sending them out. This improves consistency of the DNAME and before sending them out. This improves consistency of the DNAME and
CNAME records below the owner of the DNAME. CNAME records below the owner of the DNAME.
DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant
clients. A DNS Cache that understands DNAMEs can send out queries on
behalf of clients with the UD bit set. After receiving the answers
the DNS Cache sends replies to DNAME ignorant clients that include
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,
is displayed. It includes DNAME substitution and CNAME synthesis. is expanded to handle the UD bit.
1. Set or clear the value of recursion available in the response 1. Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide depending on whether the name server is willing to provide
recursive service. If recursive service is available and recursive service. If recursive service is available and
requested via the RD bit in the query, go to step 5, otherwise requested via the RD bit in the query, go to step 5, otherwise
step 2. step 2.
2. Search the available zones for the zone which is the nearest 2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3, ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4. otherwise step 4.
3. Start matching down, label by label, in the zone. The matching 3. Start matching down, label by label, in the zone. The matching
skipping to change at page 8, line 18 skipping to change at page 8, line 41
available from authoritative data or the cache. Go to step available from authoritative data or the cache. Go to step
4. 4.
C. If at some label, a match is impossible (i.e., the C. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see whether the corresponding label does not exist), look to see whether the
last label matched has a DNAME record. last label matched has a DNAME record.
If a DNAME record exists at that point, copy that record into If a DNAME record exists at that point, copy that record into
the answer section. If substitution of its <target> for its the answer section. If substitution of its <target> for its
<owner> in QNAME would overflow the legal size for a <domain- <owner> in QNAME would overflow the legal size for a <domain-
name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
perform the substitution and continue. The server MUST perform the substitution and continue. If the EDNS OPT
synthesize a CNAME record as described above and include it record is present in the query and the UD bit is set, the
in the answer section. Go back to step 1. server MAY copy the UD bit to the answer EDNS OPT record, and
omit CNAME synthesis. Else the server MUST synthesize a
CNAME record as described above and include it in the answer
section. Go back to step 1.
If there was no DNAME record, look to see if the "*" label If there was no DNAME record, look to see if the "*" label
exists. exists.
If the "*" label does not exist, check whether the name we If the "*" label does not exist, check whether the name we
are looking for is the original QNAME in the query or a name are looking for is the original QNAME in the query or a name
we have followed due to a CNAME or DNAME. If the name is we have followed due to a CNAME or DNAME. If the name is
original, set an authoritative name error in the response and original, set an authoritative name error in the response and
exit. Otherwise just exit. exit. Otherwise just exit.
skipping to change at page 12, line 41 skipping to change at page 13, line 41
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
DNAME Resource Record type code 39 (decimal). IANA should update the DNAME Resource Record type code 39 (decimal). IANA should update the
DNS resource record registry by adding a pointer to this document for DNS resource record registry by adding a pointer to this document for
RR type 39. No other action is required at this time. RR type 39.
This draft requests the second highest bit in the EDNS flags field
for the Understand-DNAME (UD) flag.
7. 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. redirection zone's security status.
If a validating resolver accepts wildcarded DNAMEs, this creates If a validating resolver accepts wildcarded DNAMEs, this creates
security issues. Since the processing of a wildcarded DNAME is non- security issues. Since the processing of a wildcarded DNAME is non-
deterministic and the CNAME that was substituted by the server has no deterministic and the CNAME that was substituted by the server has no
 End of changes. 17 change blocks. 
34 lines changed or deleted 64 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/