7Internet Engineering Task Force (IETF) S. Rose
8Request for Comments: 6672 NIST
9Obsoletes: 2672 W. Wijngaards
10Updates: 3363 NLnet Labs
11Category: Standards Track June 2012
15 DNAME Redirection in the DNS
19 The DNAME record provides redirection for a subtree of the domain
20 name tree in the DNS. That is, all names that end with a particular
21 suffix are redirected to another part of the DNS. This document
22 obsoletes the original specification in RFC 2672 as well as updates
23 the document on representing IPv6 addresses in DNS (RFC 3363).
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc6672.
58Rose & Wijngaards Standards Track [Page 1]
60RFC 6672 DNAME Redirection June 2012
65 Copyright (c) 2012 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
78 This document may contain material from IETF Documents or IETF
79 Contributions published or made publicly available before November
80 10, 2008. The person(s) controlling the copyright in some of this
81 material may not have granted the IETF Trust the right to allow
82 modifications of such material outside the IETF Standards Process.
83 Without obtaining an adequate license from the person(s) controlling
84 the copyright in such materials, this document may not be modified
85 outside the IETF Standards Process, and derivative works of it may
86 not be created outside the IETF Standards Process, except to format
87 it for publication as an RFC or to translate it into languages other
114Rose & Wijngaards Standards Track [Page 2]
116RFC 6672 DNAME Redirection June 2012
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
122 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
123 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 5
124 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
125 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5
126 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 6
127 2.4. Names next to and below a DNAME Record . . . . . . . . . . 7
128 2.5. Compression of the DNAME Record . . . . . . . . . . . . . 7
129 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
130 3.1. CNAME Synthesis . . . . . . . . . . . . . . . . . . . . . 8
131 3.2. Server Algorithm . . . . . . . . . . . . . . . . . . . . . 9
132 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10
133 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11
134 3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 11
135 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 12
136 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 13
137 5.1. Canonical Hostnames Cannot Be below DNAME Owners . . . . . 13
138 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
139 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14
140 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14
141 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
142 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14
143 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14
144 5.3.4.1. Invalid Name Error Response Caused by DNAME in
145 Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
146 5.3.4.2. Valid Name Error Response Involving DNAME in
147 Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
148 5.3.4.3. Response with Synthesized CNAME . . . . . . . . . 16
149 6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 16
150 6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 16
151 6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 17
152 6.3. Network Renumbering Support . . . . . . . . . . . . . . . 17
153 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
154 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
155 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
156 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
157 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
158 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
159 Appendix A. Changes from RFC 2672 . . . . . . . . . . . . . . . . 21
160 A.1. Changes to Server Behavior . . . . . . . . . . . . . . . . 21
161 A.2. Changes to Client Behavior . . . . . . . . . . . . . . . . 21
170Rose & Wijngaards Standards Track [Page 3]
172RFC 6672 DNAME Redirection June 2012
177 DNAME is a DNS resource record type originally defined in RFC 2672
178 [RFC2672]. DNAME provides redirection from a part of the DNS name
179 tree to another part of the DNS name tree.
181 The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
182 (potentially) return data corresponding to a domain name different
183 from the queried domain name. The difference between the two
184 resource records is that the CNAME RR directs the lookup of data at
185 its owner to another single name, whereas a DNAME RR directs lookups
186 for data at descendants of its owner's name to corresponding names
187 under a different (single) node of the tree.
189 For example, take looking through a zone (see RFC 1034 [RFC1034],
190 Section 4.3.2, step 3) for the domain name "foo.example.com", and a
191 DNAME resource record is found at "example.com" indicating that all
192 queries under "example.com" be directed to "example.net". The lookup
193 process will return to step 1 with the new query name of
194 "foo.example.net". Had the query name been "www.foo.example.com",
195 the new query name would be "www.foo.example.net".
197 This document is a revision of the original specification of DNAME in
198 RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
199 maintaining address-to-name mappings in a context of network
200 renumbering. With a careful setup, a renumbering event in the
201 network causes no change to the authoritative server that has the
202 address-to-name mappings. Examples in practice are classless reverse
203 address space delegations.
205 Another usage of DNAME lies in aliasing of name spaces. For example,
206 a zone administrator may want subtrees of the DNS to contain the same
207 information. Examples include punycode [RFC3492] alternates for
210 This revision of the DNAME specification does not change the wire
211 format or the handling of DNAME resource records. Discussion is
212 added on problems that may be encountered when using DNAME.
2141.1. Requirements Language
216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
217 "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and
218 "OPTIONAL" in this document are to be interpreted as described in RFC
226Rose & Wijngaards Standards Track [Page 4]
228RFC 6672 DNAME Redirection June 2012
2312. The DNAME Resource Record
235 The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is
238 Its RDATA is comprised of a single field, <target>, which contains a
239 fully qualified domain name that MUST be sent in uncompressed form
240 [RFC1035] [RFC3597]. The <target> field MUST be present. The
241 presentation format of <target> is that of a domain name [RFC1035].
242 The presentation format of the RR is as follows:
244 <owner> <ttl> <class> DNAME <target>
246 The effect of the DNAME RR is the substitution of the record's
247 <target> for its owner name, as a suffix of a domain name. This
248 substitution is to be applied for all names below the owner name of
249 the DNAME RR. This substitution has to be applied for every DNAME RR
250 found in the resolution process, which allows fairly lengthy valid
253 Details of the substitution process, methods to avoid conflicting
254 resource records, and rules for specific corner cases are given in
255 the following subsections.
2572.2. The DNAME Substitution
259 When following step 3 of the algorithm in RFC 1034 [RFC1034], Section
260 4.3.2, "start matching down, label by label, in the zone" and a node
261 is found to own a DNAME resource record, a DNAME substitution occurs.
262 The name being sought may be the original query name or a name that
263 is the result of a CNAME resource record being followed or a
264 previously encountered DNAME. As in the case when finding a CNAME
265 resource record or NS resource record set, the processing of a DNAME
266 will happen prior to finding the desired domain name.
268 A DNAME substitution is performed by replacing the suffix labels of
269 the name being sought matching the owner name of the DNAME resource
270 record with the string of labels in the RDATA field. The matching
271 labels end with the root label in all cases. Only whole labels are
272 replaced. See the table of examples for common cases and corner
275 In the table below, the QNAME refers to the query name. The owner is
276 the DNAME owner domain name, and the target refers to the target of
277 the DNAME record. The result is the resulting name after performing
278 the DNAME substitution on the query name. "no match" means that the
282Rose & Wijngaards Standards Track [Page 5]
284RFC 6672 DNAME Redirection June 2012
287 query did not match the DNAME, and thus no substitution is performed
288 and a possible error message is returned (if no other result is
289 possible). Thus, every line contains one example substitution. In
290 the examples below, 'cyc' and 'shortloop' contain loops.
292 QNAME owner DNAME target result
293 ---------------- -------------- -------------- -----------------
294 com. example.com. example.net. <no match>
295 example.com. example.com. example.net. [0]
296 a.example.com. example.com. example.net. a.example.net.
297 a.b.example.com. example.com. example.net. a.b.example.net.
298 ab.example.com. b.example.com. example.net. <no match>
299 foo.example.com. example.com. example.net. foo.example.net.
300 a.x.example.com. x.example.com. example.net. a.example.net.
301 a.example.com. example.com. y.example.net. a.y.example.net.
302 cyc.example.com. example.com. example.com. cyc.example.com.
303 cyc.example.com. example.com. c.example.com. cyc.c.example.com.
304 shortloop.x.x. x. . shortloop.x.
305 shortloop.x. x. . shortloop.
307 [0] The result depends on the QTYPE. If the QTYPE = DNAME, then
308 the result is "example.com.", else "<no match>".
310 Table 1. DNAME Substitution Examples
312 It is possible for DNAMEs to form loops, just as CNAMEs can form
313 loops. DNAMEs and CNAMEs can chain together to form loops. A single
314 corner case DNAME can form a loop. Resolvers and servers should be
315 cautious in devoting resources to a query, but be aware that fairly
316 long chains of DNAMEs may be valid. Zone content administrators
317 should take care to ensure that there are no loops that could occur
318 when using DNAME or DNAME/CNAME redirection.
320 The domain name can get too long during substitution. For example,
321 suppose the target name of the DNAME RR is 250 octets in length
322 (multiple labels), if an incoming QNAME that has a first label over 5
323 octets in length, the result would be a name over 255 octets. If
324 this occurs, the server returns an RCODE of YXDOMAIN [RFC2136]. The
325 DNAME record and its signature (if the zone is signed) are included
326 in the answer as proof for the YXDOMAIN (value 6) RCODE.
3282.3. DNAME Owner Name Matching the QNAME
330 Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
331 owner name; the owner name of a DNAME is not redirected itself. The
332 domain name that owns a DNAME record is allowed to have other
333 resource record types at that domain name, except DNAMEs, CNAMEs, or
334 other types that have restrictions on what they can coexist with.
338Rose & Wijngaards Standards Track [Page 6]
340RFC 6672 DNAME Redirection June 2012
343 When there is a match of the QTYPE to a type (or types) also owned by
344 the owner name, the response is sourced from the owner name. For
345 example, a QTYPE of ANY would return the (available) types at the
346 owner name, not the target name.
348 DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
349 the owner name is the zone apex; if it is not the zone apex, then the
350 NS RR signifies a delegation point, and the DNAME RR must in that
351 case appear below the zone cut at the zone apex of the child zone.
353 If a DNAME record is present at the zone apex, there is still a need
354 to have the customary SOA and NS resource records there as well.
355 Such a DNAME cannot be used to mirror a zone completely, as it does
356 not mirror the zone apex.
358 These rules also allow DNAME records to be queried through caches
359 that are RFC 1034 [RFC1034] compliant and are DNAME unaware.
3612.4. Names next to and below a DNAME Record
363 Resource records MUST NOT exist at any subdomain of the owner of a
364 DNAME RR. To get the contents for names subordinate to that owner
365 name, the DNAME redirection must be invoked and the resulting target
366 queried. A server MAY refuse to load a zone that has data at a
367 subdomain of a domain name owning a DNAME RR. If the server does
368 load the zone, those names below the DNAME RR will be occluded as
369 described in RFC 2136 [RFC2136], Section 7.18. Also, a server ought
370 to refuse to load a zone subordinate to the owner of a DNAME record
371 in the ancestor zone. See Section 5.2 for further discussion related
374 DNAME is a singleton type, meaning only one DNAME is allowed per
375 name. The owner name of a DNAME can only have one DNAME RR, and no
376 CNAME RRs can exist at that name. These rules make sure that for a
377 single domain name, only one redirection exists; thus, there's no
378 confusion about which one to follow. A server ought to refuse to
379 load a zone that violates these rules.
3812.5. Compression of the DNAME Record
383 The DNAME owner name can be compressed like any other owner name.
384 The DNAME RDATA target name MUST NOT be sent out in compressed form
385 and MUST be downcased for DNS Security Extensions (DNSSEC)
394Rose & Wijngaards Standards Track [Page 7]
396RFC 6672 DNAME Redirection June 2012
399 Although the previous DNAME specification [RFC2672] (that is
400 obsoleted by this specification) talked about signaling to allow
401 compression of the target name, such signaling has never been
402 specified, nor is it specified in this document.
404 RFC 2672 (obsoleted by this document) states that the Extended DNS
405 (EDNS) version has a means for understanding DNAME and DNAME target
406 name compression. This document revises RFC 2672, in that there is
407 no EDNS version signaling for DNAME.
413 When preparing a response, a server performing a DNAME substitution
414 will, in all cases, include the relevant DNAME RR in the answer
415 section. Relevant cases includes the following:
417 1. The DNAME is being employed as a substitution instruction.
419 2. The DNAME itself matches the QTYPE, and the owner name matches
422 When the owner name matches the QNAME and the QTYPE matches another
423 type owned there, the DNAME is not included in the answer.
425 A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME
426 RR is synthesized and included in the answer section when the DNAME
427 is employed as a substitution instruction. The owner name of the
428 CNAME is the QNAME of the query. The DNSSEC specification ([RFC4033]
429 [RFC4034] [RFC4035]) says that the synthesized CNAME does not have to
430 be signed. The signed DNAME has an RRSIG, and a validating resolver
431 can check the CNAME against the DNAME record and validate the
432 signature over the DNAME RR.
434 Servers MUST be able to answer a query for a synthesized CNAME. Like
435 other query types, this invokes the DNAME, and then the server
436 synthesizes the CNAME and places it into the answer section. If the
437 server in question is a cache, the synthesized CNAME's TTL SHOULD be
438 equal to the decremented TTL of the cached DNAME.
440 Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a
441 value equal to the TTL of the corresponding DNAME record (as some
442 older, authoritative server implementations set the TTL of
443 synthesized CNAMEs to zero). A TTL of zero means that the CNAME can
444 be discarded immediately after processing the answer.
450Rose & Wijngaards Standards Track [Page 8]
452RFC 6672 DNAME Redirection June 2012
457 Below is the revised version of the server algorithm, which appears
458 in RFC 2672, Section 4.1.
460 1. Set or clear the value of recursion available in the response
461 depending on whether the name server is willing to provide
462 recursive service. If recursive service is available and
463 requested via the RD bit in the query, go to step 5; otherwise,
466 2. Search the available zones for the zone which is the nearest
467 ancestor to QNAME. If such a zone is found, go to step 3;
470 3. Start matching down, label by label, in the zone. The matching
471 process can terminate several ways:
473 A. If the whole of QNAME is matched, we have found the node.
475 If the data at the node is a CNAME, and QTYPE does not match
476 CNAME, copy the CNAME RR into the answer section of the
477 response, change QNAME to the canonical name in the CNAME RR,
478 and go back to step 1.
480 Otherwise, copy all RRs which match QTYPE into the answer
481 section and go to step 6.
483 B. If a match would take us out of the authoritative data, we
484 have a referral. This happens when we encounter a node with
485 NS RRs marking cuts along the bottom of a zone.
487 Copy the NS RRs for the sub-zone into the authority section
488 of the reply. Put whatever addresses are available into the
489 additional section, using glue RRs if the addresses are not
490 available from authoritative data or the cache. Go to step
493 C. If at some label, a match is impossible (i.e., the
494 corresponding label does not exist), look to see whether the
495 last label matched has a DNAME record.
497 If a DNAME record exists at that point, copy that record into
498 the answer section. If substitution of its <target> for its
499 <owner> in QNAME would overflow the legal size for a <domain-
500 name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise,
501 perform the substitution and continue. The server MUST
506Rose & Wijngaards Standards Track [Page 9]
508RFC 6672 DNAME Redirection June 2012
511 synthesize a CNAME record as described above and include it
512 in the answer section. Go back to step 1.
514 If there was no DNAME record, look to see if the "*" label
517 If the "*" label does not exist, check whether the name we
518 are looking for is the original QNAME in the query or a name
519 we have followed due to a CNAME or DNAME. If the name is
520 original, set an authoritative name error in the response and
521 exit. Otherwise, just exit.
523 If the "*" label does exist, match RRs at that node against
524 QTYPE. If any match, copy them into the answer section, but
525 set the owner of the RR to be QNAME, and not the node with
526 the "*" label. If the data at the node with the "*" label is
527 a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
528 into the answer section of the response changing the owner
529 name to the QNAME, change QNAME to the canonical name in the
530 CNAME RR, and go back to step 1. Otherwise, go to step 6.
532 4. Start matching down in the cache. If QNAME is found in the
533 cache, copy all RRs attached to it that match QTYPE into the
534 answer section. If QNAME is not found in the cache but a DNAME
535 record is present at an ancestor of QNAME, copy that DNAME record
536 into the answer section. If there was no delegation from
537 authoritative data, look for the best one from the cache, and put
538 it in the authority section. Go to step 6.
540 5. Use the local resolver or a copy of its algorithm to answer the
541 query. Store the results, including any intermediate CNAMEs and
542 DNAMEs, in the answer section of the response.
544 6. Using local data only, attempt to add other RRs that may be
545 useful to the additional section of the query. Exit.
547 Note that there will be at most one ancestor with a DNAME as
548 described in step 4 unless some zone's data is in violation of the
549 no-descendants limitation in Section 3. An implementation might take
550 advantage of this limitation by stopping the search of step 3c or
551 step 4 when a DNAME record is encountered.
555 The use of DNAME in conjunction with wildcards is discouraged
556 [RFC4592]. Thus, records of the form "*.example.com DNAME
557 example.net" SHOULD NOT be used.
562Rose & Wijngaards Standards Track [Page 10]
564RFC 6672 DNAME Redirection June 2012
567 The interaction between the expansion of the wildcard and the
568 redirection of the DNAME is non-deterministic. Due to the fact that
569 the processing is non-deterministic, DNSSEC validating resolvers may
570 not be able to validate a wildcarded DNAME.
572 A server MAY give a warning that the behavior is unspecified if such
573 a wildcarded DNAME is loaded. The server MAY refuse it, refuse to
574 load the zone, or refuse dynamic updates.
5763.4. Acceptance and Intermediate Storage
578 Recursive caching name servers can encounter data at names below the
579 owner name of a DNAME RR, due to a change at the authoritative server
580 where data from before and after the change resides in the cache.
581 This conflict situation is a transitional phase that ends when the
582 old data times out. The caching name server can opt to store both
583 old and new data and treat each as if the other did not exist, or
584 drop the old data, or drop the longer domain name. In any approach,
585 consistency returns after the older data TTL times out.
587 Recursive caching name servers MUST perform CNAME synthesis on behalf
590 If a recursive caching name server encounters a DNSSEC validated
591 DNAME RR that contradicts information already in the cache (excluding
592 CNAME records), it SHOULD cache the DNAME RR, but it MAY cache the
593 CNAME record received along with it, subject to the rules for CNAME.
594 If the DNAME RR cannot be validated via DNSSEC (i.e., not BOGUS, but
595 not able to validate), the recursive caching server SHOULD NOT cache
596 the DNAME RR but MAY cache the CNAME record received along with it,
597 subject to the rules for CNAME.
5993.4.1. Resolver Algorithm
601 Below is the revised version of the resolver algorithm, which appears
602 in RFC 2672, Section 4.2.
604 1. See if the answer is in local information or can be synthesized
605 from a cached DNAME; if so, return it to the client.
607 2. Find the best servers to ask.
609 3. Send queries until one returns a response.
618Rose & Wijngaards Standards Track [Page 11]
620RFC 6672 DNAME Redirection June 2012
623 4. Analyze the response, either:
625 A. If the response answers the question or contains a name
626 error, cache the data as well as return it back to the
629 B. If the response contains a better delegation to other
630 servers, cache the delegation information, and go to step 2.
632 C. If the response shows a CNAME and that is not the answer
633 itself, cache the CNAME, change the SNAME to the canonical
634 name in the CNAME RR, and go to step 1.
636 D. If the response shows a DNAME and that is not the answer
637 itself, cache the DNAME (upon successful DNSSEC validation if
638 the client is a validating resolver). If substitution of the
639 DNAME's target name for its owner name in the SNAME would
640 overflow the legal size for a domain name, return an
641 implementation-dependent error to the application; otherwise,
642 perform the substitution and go to step 1.
644 E. If the response shows a server failure or other bizarre
645 contents, delete the server from the SLIST and go back to
6484. DNAME Discussions in Other Documents
650 In Section 10.3 of [RFC2181], the discussion on MX and NS records
651 touches on redirection by CNAMEs, but this also holds for DNAMEs.
653 Section 10.3 ("MX and NS records") of [RFC2181] states:
655 The domain name used as the value of a NS resource record,
656 or part of the value of a MX resource record must not be
657 an alias. Not only is the specification clear on this
658 point, but using an alias in either of these positions
659 neither works as well as might be hoped, nor well fulfills
660 the ambition that may have led to this approach. This
661 domain name must have as its value one or more address
662 records. Currently those will be A records, however in
663 the future other record types giving addressing
664 information may be acceptable. It can also have other
665 RRs, but never a CNAME RR.
667 The DNAME RR is discussed in RFC 3363, Section 4, on A6 and DNAME.
668 The opening premise of this section is demonstrably wrong, and so the
669 conclusion based on that premise is wrong. In particular, [RFC3363]
670 deprecates the use of DNAME in the IPv6 reverse tree. Based on the
674Rose & Wijngaards Standards Track [Page 12]
676RFC 6672 DNAME Redirection June 2012
679 experience gained in the meantime, [RFC3363] is revised, dropping all
680 constraints on having DNAME RRs in these zones [RFC6434]. This would
681 greatly improve the manageability of the IPv6 reverse tree. These
682 changes are made explicit below.
684 In [RFC3363], the following paragraph is updated by this document,
685 and the use of DNAME RRs in the reverse tree is no longer deprecated.
687 The issues for DNAME in the reverse mapping tree appears to be
688 closely tied to the need to use fragmented A6 in the main tree: if
689 one is necessary, so is the other, and if one isn't necessary, the
690 other isn't either. Therefore, in moving RFC 2874 to experimental,
691 the intent of this document is that use of DNAME RRs in the reverse
6945. Other Issues with DNAME
696 There are several issues to be aware of about the use of DNAME.
6985.1. Canonical Hostnames Cannot Be below DNAME Owners
700 The names listed as target names of MX, NS, PTR, and SRV [RFC2782]
701 records must be canonical hostnames. This means no CNAME or DNAME
702 redirection may be present during DNS lookup of the address records
703 for the host. This is discussed in RFC 2181 [RFC2181], Section 10.3,
704 and RFC 1912 [RFC1912], Section 2.4. For SRV, see RFC 2782
707 The upshot of this is that although the lookup of a PTR record can
708 involve DNAMEs, the name listed in the PTR record cannot fall under a
709 DNAME. The same holds for NS, SRV, and MX records. For example,
710 when punycode [RFC3492] alternates for a zone use DNAME, then the NS,
711 MX, SRV, and PTR records that point to that zone must use names that
712 are not aliases in their RDATA. Then, what must be done is to have
713 the domain names with DNAME substitution already applied to it as the
714 MX, NS, PTR, and SRV data. These are valid canonical hostnames.
7165.2. Dynamic Update and DNAME
718 DNAME records can be added, changed, and removed in a zone using
719 dynamic update transactions. Adding a DNAME RR to a zone occludes
720 any domain names that may exist under the added DNAME.
722 If a dynamic update message attempts to add a DNAME with a given
723 owner name, but a CNAME is associated with that name, then the server
724 MUST ignore the DNAME. If a DNAME is already associated with that
725 name, then it is replaced with the new DNAME. Otherwise, add the
726 DNAME. If a CNAME is added with a given owner name, but a DNAME is
730Rose & Wijngaards Standards Track [Page 13]
732RFC 6672 DNAME Redirection June 2012
735 associated with that name, then the CNAME MUST be ignored. Similar
736 behavior occurs for dynamic updates to an owner name of a CNAME RR
741 The following subsections specify the behavior of implementations
742 that understand both DNSSEC and DNAME (synthesis).
7445.3.1. Signed DNAME, Unsigned Synthesized CNAME
746 In any response, a signed DNAME RR indicates a non-terminal
747 redirection of the query. There might or might not be a server-
748 synthesized CNAME in the answer section; if there is, the CNAME will
749 never be signed. For a DNSSEC validator, verification of the DNAME
750 RR and then that the CNAME was properly synthesized is sufficient
7535.3.2. DNAME Bit in NSEC Type Map
755 In any negative response, the NSEC or NSEC3 [RFC5155] record type
756 bitmap SHOULD be checked to see that there was no DNAME that could
757 have been applied. If the DNAME bit in the type bitmap is set and
758 the query name is a subdomain of the closest encloser that is
759 asserted, then DNAME substitution should have been done, but the
760 substitution has not been done as specified.
7625.3.3. DNAME Chains as Strong as the Weakest Link
764 A response can contain a chain of DNAME and CNAME redirections. That
765 chain can end in a positive answer or a negative reply (no name error
766 or no data error). Each step in that chain results in resource
767 records being added to the answer or authority section of the
768 response. Only if all steps are secure can the AD (Authentic Data)
769 bit be set for the response. If one of the steps is bogus, the
7725.3.4. Validators Must Understand DNAME
774 Below are examples of why DNSSEC validators MUST understand DNAME.
775 In the examples, SOA records, wildcard denial NSECs, and other
776 material not under discussion have been omitted or shortened.
786Rose & Wijngaards Standards Track [Page 14]
788RFC 6672 DNAME Redirection June 2012
7915.3.4.1. Invalid Name Error Response Caused by DNAME in Bitmap
793 ;; Header: QR AA RCODE=3(NXDOMAIN)
794 ;; OPT PSEUDOSECTION:
795 ; EDNS: version: 0, flags: do; udp: 4096
798 foo.bar.example.com. IN A
800 bar.example.com. NSEC dub.example.com. A DNAME
801 bar.example.com. RRSIG NSEC [valid signature]
803 If this is the received response, then only by understanding that the
804 DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
805 have been redirected by the DNAME, the validator can see that it is a
806 BOGUS reply from an attacker that collated existing records from the
807 DNS to create a confusing reply.
809 If the DNAME bit had not been set in the NSEC record above, then the
810 answer would have validated as a correct name error response.
8125.3.4.2. Valid Name Error Response Involving DNAME in Bitmap
814 ;; Header: QR AA RCODE=3(NXDOMAIN)
815 ;; OPT PSEUDOSECTION:
816 ; EDNS: version: 0, flags: do; udp: 4096
819 cee.example.com. IN A
821 bar.example.com. NSEC dub.example.com. A DNAME
822 bar.example.com. RRSIG NSEC [valid signature]
824 This response has the same NSEC records as the example above, but
825 with this query name (cee.example.com), the answer is validated,
826 because 'cee' does not get redirected by the DNAME at 'bar'.
842Rose & Wijngaards Standards Track [Page 15]
844RFC 6672 DNAME Redirection June 2012
8475.3.4.3. Response with Synthesized CNAME
849 ;; Header: QR AA RCODE=0(NOERROR)
850 ;; OPT PSEUDOSECTION:
851 ; EDNS: version: 0, flags: do; udp: 4096
854 foo.bar.example.com. IN A
856 bar.example.com. DNAME bar.example.net.
857 bar.example.com. RRSIG DNAME [valid signature]
858 foo.bar.example.com. CNAME foo.bar.example.net.
860 The response shown above has the synthesized CNAME included.
861 However, the CNAME has no signature, since the server does not sign
862 online. So this response cannot be trusted. It could be altered by
863 an attacker to be foo.bar.example.com CNAME bla.bla.example. The
864 DNAME record does have its signature included, since it does not
865 change. The validator must verify the DNAME signature and then
866 recursively resolve further in order to query for the
867 foo.bar.example.net A record.
8696. Examples of DNAME Use in a Zone
871 Below are some examples of the use of DNAME in a zone. These
872 examples are by no means exhaustive.
8746.1. Organizational Renaming
876 If an organization with domain name FROBOZZ.EXAMPLE.NET became part
877 of an organization with domain name ACME.EXAMPLE.COM, it might ease
878 transition by placing information such as this in its old zone.
880 frobozz.example.net. DNAME frobozz-division.acme.example.com.
881 MX 10 mailhub.acme.example.com.
883 The response to an extended recursive query for
884 www.frobozz.example.net would contain, in the answer section, the
885 DNAME record shown above and the relevant RRs for www.frobozz-
886 division.acme.example.com.
888 If an organization wants to have aliases for names, for a different
889 spelling or language, the same example applies. Note that the MX RR
890 at the zone apex is not redirected and has to be repeated in the
891 target zone. Also note that the services at mailhub or www.frobozz-
892 division.acme.example.com. have to recognize and handle the aliases.
898Rose & Wijngaards Standards Track [Page 16]
900RFC 6672 DNAME Redirection June 2012
9036.2. Classless Delegation of Shorter Prefixes
905 The classless scheme for in-addr.arpa delegation [RFC2317] can be
906 extended to prefixes shorter than 24 bits by use of the DNAME record.
907 For example, the prefix 192.0.8.0/22 can be delegated by the
910 $ORIGIN 0.192.in-addr.arpa.
911 8/22 NS ns.slash-22-holder.example.com.
917 A typical entry in the resulting reverse zone for some host with
918 address 192.0.9.33 might be as follows:
920 $ORIGIN 8/22.0.192.in-addr.arpa.
921 33.9 PTR somehost.slash-22-holder.example.com.
923 The advisory remarks in [RFC2317] concerning the choice of the "/"
924 character apply here as well.
9266.3. Network Renumbering Support
928 If IPv4 network renumbering were common, maintenance of address space
929 delegation could be simplified by using DNAME records instead of NS
932 $ORIGIN new-style.in-addr.arpa.
933 189.190 DNAME in-addr.example.net.
935 $ORIGIN in-addr.example.net.
936 188 DNAME in-addr.customer.example.com.
938 $ORIGIN in-addr.customer.example.
939 1 PTR www.customer.example.com
940 2 PTR mailhub.customer.example.com.
943 This would allow the address space 190.189.0.0/16 assigned to the ISP
944 "example.net" to be changed without having to alter the zone data
945 describing the use of that space by the ISP and its customers.
954Rose & Wijngaards Standards Track [Page 17]
956RFC 6672 DNAME Redirection June 2012
959 Renumbering IPv4 networks is currently so arduous a task that
960 updating the DNS is only a small part of the labor, so this scheme
961 may have a low value. But it is hoped that in IPv6 the renumbering
962 task will be quite different, and the DNAME mechanism may play a
9657. IANA Considerations
967 The DNAME resource record type code 39 (decimal) originally was
968 registered by [RFC2672] in the DNS Resource Record (RR) Types
969 registry table at http://www.iana.org/assignments/dns-parameters.
970 IANA has updated the DNS resource record registry to point to this
971 document for RR type 39.
9738. Security Considerations
975 DNAME redirects queries elsewhere, which may impact security based on
976 policy and the security status of the zone with the DNAME and the
977 redirection zone's security status. For validating resolvers, the
978 lowest security status of the links in the chain of CNAME and DNAME
979 redirections is applied to the result.
981 If a validating resolver accepts wildcarded DNAMEs, this creates
982 security issues. Since the processing of a wildcarded DNAME is non-
983 deterministic and the CNAME that was substituted by the server has no
984 signature, the resolver may choose a different result than what the
985 server meant, and consequently end up at the wrong destination. Use
986 of wildcarded DNAMEs is discouraged in any case [RFC4592].
988 A validating resolver MUST understand DNAME, according to [RFC4034].
989 The examples in Section 5.3.4 illustrate this need.
993 The authors of this document would like to acknowledge Matt Larson
994 for beginning this effort to address the issues related to the DNAME
995 RR type. The authors would also like to acknowledge Paul Vixie, Ed
996 Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
997 Hoenes, and Kevin Darcy for their reviews and comments on this
1010Rose & Wijngaards Standards Track [Page 18]
1012RFC 6672 DNAME Redirection June 2012
101710.1. Normative References
1019 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1020 STD 13, RFC 1034, November 1987.
1022 [RFC1035] Mockapetris, P., "Domain names - implementation and
1023 specification", STD 13, RFC 1035, November 1987.
1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1026 Requirement Levels", BCP 14, RFC 2119, March 1997.
1028 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1029 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1030 RFC 2136, April 1997.
1032 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1033 Specification", RFC 2181, July 1997.
1035 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
1036 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
1038 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
1039 specifying the location of services (DNS SRV)", RFC 2782,
1042 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
1043 (RR) Types", RFC 3597, September 2003.
1045 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1046 Rose, "DNS Security Introduction and Requirements",
1047 RFC 4033, March 2005.
1049 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1050 Rose, "Resource Records for the DNS Security Extensions",
1051 RFC 4034, March 2005.
1053 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1054 Rose, "Protocol Modifications for the DNS Security
1055 Extensions", RFC 4035, March 2005.
1057 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
1058 System", RFC 4592, July 2006.
1060 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
1061 Security (DNSSEC) Hashed Authenticated Denial of
1062 Existence", RFC 5155, March 2008.
1066Rose & Wijngaards Standards Track [Page 19]
1068RFC 6672 DNAME Redirection June 2012
107110.2. Informative References
1073 [RFC1912] Barr, D., "Common DNS Operational and Configuration
1074 Errors", RFC 1912, February 1996.
1076 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
1077 RFC 2672, August 1999.
1079 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
1080 Hain, "Representing Internet Protocol version 6 (IPv6)
1081 Addresses in the Domain Name System (DNS)", RFC 3363,
1084 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1085 for Internationalized Domain Names in Applications
1086 (IDNA)", RFC 3492, March 2003.
1088 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
1089 Requirements", RFC 6434, December 2011.
1122Rose & Wijngaards Standards Track [Page 20]
1124RFC 6672 DNAME Redirection June 2012
1127Appendix A. Changes from RFC 2672
1129A.1. Changes to Server Behavior
1131 Major changes to server behavior from the original DNAME
1132 specification are summarized below:
1134 o The rules for DNAME substitution have been clarified in
1137 o The EDNS option to signal DNAME understanding and compression has
1138 never been specified, and this document clarifies that there is no
1139 signaling method (Section 2.5).
1141 o The TTL for synthesized CNAME RRs is now set to the TTL of the
1142 DNAME, not zero (Section 3.1).
1144 o Recursive caching servers MUST perform CNAME synthesis on behalf
1145 of clients (Section 3.4).
1147 o The revised server algorithm is detailed in Section 3.2.
1149 o Rules for dynamic update messages adding a DNAME or CNAME RR to a
1150 zone where a CNAME or DNAME already exists are detailed in
1153A.2. Changes to Client Behavior
1155 Major changes to client behavior from the original DNAME
1156 specification are summarized below:
1158 o Clients MUST be able to accept synthesized CNAME RR's with a TTL
1159 of either zero or the TTL of the DNAME RR that accompanies the
1162 o DNSSEC-aware clients SHOULD cache DNAME RRs and MAY cache
1163 synthesized CNAME RRs they receive in the same response. DNSSEC-
1164 aware clients SHOULD also check the NSEC/NSEC3 type bitmap to
1165 verify that DNAME redirection is to be done. DNSSEC validators
1166 MUST understand DNAME (Section 5.3).
1168 o The revised client algorithm is detailed in Section 3.4.1.
1178Rose & Wijngaards Standards Track [Page 21]
1180RFC 6672 DNAME Redirection June 2012
1188 Gaithersburg, MD 20899
1191 Phone: +1-301-975-8439
1192 Fax: +1-301-975-6238
1193 EMail: scott.rose@nist.gov
1202 Phone: +31-20-888-4551
1203 EMail: wouter@nlnetlabs.nl
1234Rose & Wijngaards Standards Track [Page 22]