draft-ietf-dnsext-rfc2672bis-dname-09.txt   draft-ietf-dnsext-rfc2672bis-dname-10.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 February 5, 2008 Intended status: Standards Track February 21, 2008
Expires: August 8, 2008 Expires: August 24, 2008
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-09 draft-ietf-dnsext-rfc2672bis-dname-10
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 August 8, 2008. This Internet-Draft will expire on August 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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
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 . . . . . . . . . . . . . . . . . . . . . 12 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 12 5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 11
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
skipping to change at page 5, line 46 skipping to change at page 5, line 46
1034 [RFC1034] caches. 1034 [RFC1034] caches.
This means that DNAME RRs are not allowed at the parent side of a This means that DNAME RRs are not allowed at the parent side of a
delegation point but are allowed at a zone apex. 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 at a domain name subordinate to Other resource records MUST NOT exist at a domain name subordinate to
the owner of a DNAME RR. To get the contents for names subordinate the owner of a DNAME RR. To get the contents for names subordinate
to that owner, the DNAME redirection must be invoked and the to that owner, the DNAME redirection must be invoked and the
resulting target queried. A server SHOULD refuse to load a zone that resulting target queried. A server MAY refuse to load a zone that
has data at a domain name subordinate to a domain name owning a DNAME has data at a domain name subordinate to a domain name owning a DNAME
RR. Also a server SHOULD refuse to load a zone subordinate to the RR. If the server does load the zone, those names below the DNAME RR
owner of a DNAME record in the ancestor zone. See Section 5.2 for should be occluded. Also a server SHOULD refuse to load a zone
further restrictions related to dynamic update. subordinate to the owner of a DNAME record in the ancestor zone. See
Section 5.2 for further discussion 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 17 skipping to change at page 7, line 17
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.
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. A 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
request omission of the synthesized CNAMEs. Servers copy the UD bit request omission of the synthesized CNAMEs. Servers copy the UD bit
to the response, and can omit synthesized CNAMEs from the answer. to the response, and can omit synthesized CNAMEs from the answer.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
Updated EDNS extended RCODE and Flags field. Updated EDNS extended RCODE and Flags field.
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION | 0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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. Like
answer containing the synthesized CNAME cannot contain an error other query types this invokes the DNAME, and synthesizes the CNAME
(since a CNAME has been followed), as per RFC 1034 CNAME rules. into the answer.
3.3. Acceptance and Intermediate Storage 3.3. Acceptance and Intermediate Storage
DNS caches can encounter data at names below the owner name of a DNS caches can encounter data at names below the owner name of a
DNAME RR, due to a change at the authoritative server where data from DNAME RR, due to a change at the authoritative server where data from
before and after the change resides in the cache. This conflict before and after the change resides in the cache. This conflict
situation is a transitional phase, that ends when the old data times situation is a transitional phase, that ends when the old data times
out. The cache can opt to store both old and new data and treat each out. The cache can opt to store both old and new data and treat each
as if the other did not exist, or drop the old data, or drop the 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 longer domain name. In any approach, consistency returns after the
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 DNAME records can be added, changed and removed in a zone using
delegating NS records. For example, adding a DNAME obscures names in dynamic update transactions. Adding a DNAME RR to a zone occludes
the zone. DNAME records can be added, changed and removed. any domain names that may exist under the added DNAME.
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
DNAME.
A server MUST return an error message with RCODE=YXDOMAIN [RFC2136] A server MUST ignore a dynamic update message that attempts to add a
in response to a dynamic update message that would add a resource DNAME RR at a name that already has one or more RRs associated with
record under a DNAME in the zone. This is similar to a dynamic that name.
update request to add a resource record under a delegation NS in a
zone.
5.3. DNSSEC and DNAME 5.3. DNSSEC and DNAME
5.3.1. DNAME bit in NSEC type map 5.3.1. DNAME bit in NSEC type map
When a validator checks the NSEC RRs returned on a name error When a validator checks the NSEC RRs returned on a name error
response, it SHOULD check that the DNAME bit is not set. If the response, it SHOULD check that the DNAME bit is not set. If the
DNAME bit is set then the DNAME substitution should have been done, DNAME bit is set then the DNAME substitution should have been done,
but has not. but has not.
 End of changes. 10 change blocks. 
26 lines changed or deleted 21 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/