1 Internet Engineering Task Force (IETF) S. Rose
2 Request for Comments: 6672 NIST
3 Obsoletes: 2672 W. Wijngaards
4 Updates: 3363 NLnet Labs
5 Category: Standards Track June 2012
6 ISSN: 2070-1721
7
8
9 DNAME Redirection in the DNS
10
11 Abstract
12
13 The DNAME record provides redirection for a subtree of the domain
14 name tree in the DNS. That is, all names that end with a particular
15 suffix are redirected to another part of the DNS. This document
16 obsoletes the original specification in RFC 2672 as well as updates
17 the document on representing IPv6 addresses in DNS (RFC 3363).
18
19 Status of This Memo
20
21 This is an Internet Standards Track document.
22
23 This document is a product of the Internet Engineering Task Force
24 (IETF). It represents the consensus of the IETF community. It has
25 received public review and has been approved for publication by the
26 Internet Engineering Steering Group (IESG). Further information on
27 Internet Standards is available in Section 2 of RFC 5741.
28
29 Information about the current status of this document, any errata,
30 and how to provide feedback on it may be obtained at
31 http://www.rfc-editor.org/info/rfc6672.
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Rose & Wijngaards Standards Track [Page 1]
53 RFC 6672 DNAME Redirection June 2012
54
55
56 Copyright Notice
57
58 Copyright (c) 2012 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 This document may contain material from IETF Documents or IETF
72 Contributions published or made publicly available before November
73 10, 2008. The person(s) controlling the copyright in some of this
74 material may not have granted the IETF Trust the right to allow
75 modifications of such material outside the IETF Standards Process.
76 Without obtaining an adequate license from the person(s) controlling
77 the copyright in such materials, this document may not be modified
78 outside the IETF Standards Process, and derivative works of it may
79 not be created outside the IETF Standards Process, except to format
80 it for publication as an RFC or to translate it into languages other
81 than English.
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Rose & Wijngaards Standards Track [Page 2]
108 RFC 6672 DNAME Redirection June 2012
109
110
111 Table of Contents
112
113 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
114 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
115 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 5
116 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
117 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5
118 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 6
119 2.4. Names next to and below a DNAME Record . . . . . . . . . . 7
120 2.5. Compression of the DNAME Record . . . . . . . . . . . . . 7
121 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
122 3.1. CNAME Synthesis . . . . . . . . . . . . . . . . . . . . . 8
123 3.2. Server Algorithm . . . . . . . . . . . . . . . . . . . . . 9
124 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10
125 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11
126 3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 11
127 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 12
128 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 13
129 5.1. Canonical Hostnames Cannot Be below DNAME Owners . . . . . 13
130 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
131 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14
132 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14
133 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
134 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14
135 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14
136 5.3.4.1. Invalid Name Error Response Caused by DNAME in
137 Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
138 5.3.4.2. Valid Name Error Response Involving DNAME in
139 Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
140 5.3.4.3. Response with Synthesized CNAME . . . . . . . . . 16
141 6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 16
142 6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 16
143 6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 17
144 6.3. Network Renumbering Support . . . . . . . . . . . . . . . 17
145 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
146 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
147 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
148 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
149 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
150 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
151 Appendix A. Changes from RFC 2672 . . . . . . . . . . . . . . . . 21
152 A.1. Changes to Server Behavior . . . . . . . . . . . . . . . . 21
153 A.2. Changes to Client Behavior . . . . . . . . . . . . . . . . 21
154
155
156
157
158
159
160
161
162 Rose & Wijngaards Standards Track [Page 3]
163 RFC 6672 DNAME Redirection June 2012
164
165
166 1. Introduction
167
168 DNAME is a DNS resource record type originally defined in RFC 2672
169 [RFC2672]. DNAME provides redirection from a part of the DNS name
170 tree to another part of the DNS name tree.
171
172 The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
173 (potentially) return data corresponding to a domain name different
174 from the queried domain name. The difference between the two
175 resource records is that the CNAME RR directs the lookup of data at
176 its owner to another single name, whereas a DNAME RR directs lookups
177 for data at descendants of its owner's name to corresponding names
178 under a different (single) node of the tree.
179
180 For example, take looking through a zone (see RFC 1034 [RFC1034],
181 Section 4.3.2, step 3) for the domain name "foo.example.com", and a
182 DNAME resource record is found at "example.com" indicating that all
183 queries under "example.com" be directed to "example.net". The lookup
184 process will return to step 1 with the new query name of
185 "foo.example.net". Had the query name been "www.foo.example.com",
186 the new query name would be "www.foo.example.net".
187
188 This document is a revision of the original specification of DNAME in
189 RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
190 maintaining address-to-name mappings in a context of network
191 renumbering. With a careful setup, a renumbering event in the
192 network causes no change to the authoritative server that has the
193 address-to-name mappings. Examples in practice are classless reverse
194 address space delegations.
195
196 Another usage of DNAME lies in aliasing of name spaces. For example,
197 a zone administrator may want subtrees of the DNS to contain the same
198 information. Examples include punycode [RFC3492] alternates for
199 domain spaces.
200
201 This revision of the DNAME specification does not change the wire
202 format or the handling of DNAME resource records. Discussion is
203 added on problems that may be encountered when using DNAME.
204
205 1.1. Requirements Language
206
207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
208 "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and
209 "OPTIONAL" in this document are to be interpreted as described in RFC
210 2119 [RFC2119].
211
212
213
214
215
216
217 Rose & Wijngaards Standards Track [Page 4]
218 RFC 6672 DNAME Redirection June 2012
219
220
221 2. The DNAME Resource Record
222
223 2.1. Format
224
225 The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is
226 CLASS-insensitive.
227
228 Its RDATA is comprised of a single field, <target>, which contains a
229 fully qualified domain name that MUST be sent in uncompressed form
230 [RFC1035] [RFC3597]. The <target> field MUST be present. The
231 presentation format of <target> is that of a domain name [RFC1035].
232 The presentation format of the RR is as follows:
233
234 <owner> <ttl> <class> DNAME <target>
235
236 The effect of the DNAME RR is the substitution of the record's
237 <target> for its owner name, as a suffix of a domain name. This
238 substitution is to be applied for all names below the owner name of
239 the DNAME RR. This substitution has to be applied for every DNAME RR
240 found in the resolution process, which allows fairly lengthy valid
241 chains of DNAME RRs.
242
243 Details of the substitution process, methods to avoid conflicting
244 resource records, and rules for specific corner cases are given in
245 the following subsections.
246
247 2.2. The DNAME Substitution
248
249 When following step 3 of the algorithm in RFC 1034 [RFC1034], Section
250 4.3.2, "start matching down, label by label, in the zone" and a node
251 is found to own a DNAME resource record, a DNAME substitution occurs.
252 The name being sought may be the original query name or a name that
253 is the result of a CNAME resource record being followed or a
254 previously encountered DNAME. As in the case when finding a CNAME
255 resource record or NS resource record set, the processing of a DNAME
256 will happen prior to finding the desired domain name.
257
258 A DNAME substitution is performed by replacing the suffix labels of
259 the name being sought matching the owner name of the DNAME resource
260 record with the string of labels in the RDATA field. The matching
261 labels end with the root label in all cases. Only whole labels are
262 replaced. See the table of examples for common cases and corner
263 cases.
264
265 In the table below, the QNAME refers to the query name. The owner is
266 the DNAME owner domain name, and the target refers to the target of
267 the DNAME record. The result is the resulting name after performing
268 the DNAME substitution on the query name. "no match" means that the
269
270
271
272 Rose & Wijngaards Standards Track [Page 5]
273 RFC 6672 DNAME Redirection June 2012
274
275
276 query did not match the DNAME, and thus no substitution is performed
277 and a possible error message is returned (if no other result is
278 possible). Thus, every line contains one example substitution. In
279 the examples below, 'cyc' and 'shortloop' contain loops.
280
281 QNAME owner DNAME target result
282 ---------------- -------------- -------------- -----------------
283 com. example.com. example.net. <no match>
284 example.com. example.com. example.net. [0]
285 a.example.com. example.com. example.net. a.example.net.
286 a.b.example.com. example.com. example.net. a.b.example.net.
287 ab.example.com. b.example.com. example.net. <no match>
288 foo.example.com. example.com. example.net. foo.example.net.
289 a.x.example.com. x.example.com. example.net. a.example.net.
290 a.example.com. example.com. y.example.net. a.y.example.net.
291 cyc.example.com. example.com. example.com. cyc.example.com.
292 cyc.example.com. example.com. c.example.com. cyc.c.example.com.
293 shortloop.x.x. x. . shortloop.x.
294 shortloop.x. x. . shortloop.
295
296 [0] The result depends on the QTYPE. If the QTYPE = DNAME, then
297 the result is "example.com.", else "<no match>".
298
299 Table 1. DNAME Substitution Examples
300
301 It is possible for DNAMEs to form loops, just as CNAMEs can form
302 loops. DNAMEs and CNAMEs can chain together to form loops. A single
303 corner case DNAME can form a loop. Resolvers and servers should be
304 cautious in devoting resources to a query, but be aware that fairly
305 long chains of DNAMEs may be valid. Zone content administrators
306 should take care to ensure that there are no loops that could occur
307 when using DNAME or DNAME/CNAME redirection.
308
309 The domain name can get too long during substitution. For example,
310 suppose the target name of the DNAME RR is 250 octets in length
311 (multiple labels), if an incoming QNAME that has a first label over 5
312 octets in length, the result would be a name over 255 octets. If
313 this occurs, the server returns an RCODE of YXDOMAIN [RFC2136]. The
314 DNAME record and its signature (if the zone is signed) are included
315 in the answer as proof for the YXDOMAIN (value 6) RCODE.
316
317 2.3. DNAME Owner Name Matching the QNAME
318
319 Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
320 owner name; the owner name of a DNAME is not redirected itself. The
321 domain name that owns a DNAME record is allowed to have other
322 resource record types at that domain name, except DNAMEs, CNAMEs, or
323 other types that have restrictions on what they can coexist with.
324
325
326
327 Rose & Wijngaards Standards Track [Page 6]
328 RFC 6672 DNAME Redirection June 2012
329
330
331 When there is a match of the QTYPE to a type (or types) also owned by
332 the owner name, the response is sourced from the owner name. For
333 example, a QTYPE of ANY would return the (available) types at the
334 owner name, not the target name.
335
336 DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
337 the owner name is the zone apex; if it is not the zone apex, then the
338 NS RR signifies a delegation point, and the DNAME RR must in that
339 case appear below the zone cut at the zone apex of the child zone.
340
341 If a DNAME record is present at the zone apex, there is still a need
342 to have the customary SOA and NS resource records there as well.
343 Such a DNAME cannot be used to mirror a zone completely, as it does
344 not mirror the zone apex.
345
346 These rules also allow DNAME records to be queried through caches
347 that are RFC 1034 [RFC1034] compliant and are DNAME unaware.
348
349 2.4. Names next to and below a DNAME Record
350
351 Resource records MUST NOT exist at any subdomain of the owner of a
352 DNAME RR. To get the contents for names subordinate to that owner
353 name, the DNAME redirection must be invoked and the resulting target
354 queried. A server MAY refuse to load a zone that has data at a
355 subdomain of a domain name owning a DNAME RR. If the server does
356 load the zone, those names below the DNAME RR will be occluded as
357 described in RFC 2136 [RFC2136], Section 7.18. Also, a server ought
358 to refuse to load a zone subordinate to the owner of a DNAME record
359 in the ancestor zone. See Section 5.2 for further discussion related
360 to dynamic update.
361
362 DNAME is a singleton type, meaning only one DNAME is allowed per
363 name. The owner name of a DNAME can only have one DNAME RR, and no
364 CNAME RRs can exist at that name. These rules make sure that for a
365 single domain name, only one redirection exists; thus, there's no
366 confusion about which one to follow. A server ought to refuse to
367 load a zone that violates these rules.
368
369 2.5. Compression of the DNAME Record
370
371 The DNAME owner name can be compressed like any other owner name.
372 The DNAME RDATA target name MUST NOT be sent out in compressed form
373 and MUST be downcased for DNS Security Extensions (DNSSEC)
374 validation.
375
376
377
378
379
380
381
382 Rose & Wijngaards Standards Track [Page 7]
383 RFC 6672 DNAME Redirection June 2012
384
385
386 Although the previous DNAME specification [RFC2672] (that is
387 obsoleted by this specification) talked about signaling to allow
388 compression of the target name, such signaling has never been
389 specified, nor is it specified in this document.
390
391 RFC 2672 (obsoleted by this document) states that the Extended DNS
392 (EDNS) version has a means for understanding DNAME and DNAME target
393 name compression. This document revises RFC 2672, in that there is
394 no EDNS version signaling for DNAME.
395
396 3. Processing
397
398 3.1. CNAME Synthesis
399
400 When preparing a response, a server performing a DNAME substitution
401 will, in all cases, include the relevant DNAME RR in the answer
402 section. Relevant cases includes the following:
403
404 1. The DNAME is being employed as a substitution instruction.
405
406 2. The DNAME itself matches the QTYPE, and the owner name matches
407 QNAME.
408
409 When the owner name matches the QNAME and the QTYPE matches another
410 type owned there, the DNAME is not included in the answer.
411
412 A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME
413 RR is synthesized and included in the answer section when the DNAME
414 is employed as a substitution instruction. The owner name of the
415 CNAME is the QNAME of the query. The DNSSEC specification ([RFC4033]
416 [RFC4034] [RFC4035]) says that the synthesized CNAME does not have to
417 be signed. The signed DNAME has an RRSIG, and a validating resolver
418 can check the CNAME against the DNAME record and validate the
419 signature over the DNAME RR.
420
421 Servers MUST be able to answer a query for a synthesized CNAME. Like
422 other query types, this invokes the DNAME, and then the server
423 synthesizes the CNAME and places it into the answer section. If the
424 server in question is a cache, the synthesized CNAME's TTL SHOULD be
425 equal to the decremented TTL of the cached DNAME.
426
427 Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a
428 value equal to the TTL of the corresponding DNAME record (as some
429 older, authoritative server implementations set the TTL of
430 synthesized CNAMEs to zero). A TTL of zero means that the CNAME can
431 be discarded immediately after processing the answer.
432
433
434
435
436
437 Rose & Wijngaards Standards Track [Page 8]
438 RFC 6672 DNAME Redirection June 2012
439
440
441 3.2. Server Algorithm
442
443 Below is the revised version of the server algorithm, which appears
444 in RFC 2672, Section 4.1.
445
446 1. Set or clear the value of recursion available in the response
447 depending on whether the name server is willing to provide
448 recursive service. If recursive service is available and
449 requested via the RD bit in the query, go to step 5; otherwise,
450 step 2.
451
452 2. Search the available zones for the zone which is the nearest
453 ancestor to QNAME. If such a zone is found, go to step 3;
454 otherwise, step 4.
455
456 3. Start matching down, label by label, in the zone. The matching
457 process can terminate several ways:
458
459 A. If the whole of QNAME is matched, we have found the node.
460
461 If the data at the node is a CNAME, and QTYPE does not match
462 CNAME, copy the CNAME RR into the answer section of the
463 response, change QNAME to the canonical name in the CNAME RR,
464 and go back to step 1.
465
466 Otherwise, copy all RRs which match QTYPE into the answer
467 section and go to step 6.
468
469 B. If a match would take us out of the authoritative data, we
470 have a referral. This happens when we encounter a node with
471 NS RRs marking cuts along the bottom of a zone.
472
473 Copy the NS RRs for the sub-zone into the authority section
474 of the reply. Put whatever addresses are available into the
475 additional section, using glue RRs if the addresses are not
476 available from authoritative data or the cache. Go to step
477 4.
478
479 C. If at some label, a match is impossible (i.e., the
480 corresponding label does not exist), look to see whether the
481 last label matched has a DNAME record.
482
483 If a DNAME record exists at that point, copy that record into
484 the answer section. If substitution of its <target> for its
485 <owner> in QNAME would overflow the legal size for a <domain-
486 name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise,
487 perform the substitution and continue. The server MUST
488
489
490
491
492 Rose & Wijngaards Standards Track [Page 9]
493 RFC 6672 DNAME Redirection June 2012
494
495
496 synthesize a CNAME record as described above and include it
497 in the answer section. Go back to step 1.
498
499 If there was no DNAME record, look to see if the "*" label
500 exists.
501
502 If the "*" label does not exist, check whether the name we
503 are looking for is the original QNAME in the query or a name
504 we have followed due to a CNAME or DNAME. If the name is
505 original, set an authoritative name error in the response and
506 exit. Otherwise, just exit.
507
508 If the "*" label does exist, match RRs at that node against
509 QTYPE. If any match, copy them into the answer section, but
510 set the owner of the RR to be QNAME, and not the node with
511 the "*" label. If the data at the node with the "*" label is
512 a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
513 into the answer section of the response changing the owner
514 name to the QNAME, change QNAME to the canonical name in the
515 CNAME RR, and go back to step 1. Otherwise, go to step 6.
516
517 4. Start matching down in the cache. If QNAME is found in the
518 cache, copy all RRs attached to it that match QTYPE into the
519 answer section. If QNAME is not found in the cache but a DNAME
520 record is present at an ancestor of QNAME, copy that DNAME record
521 into the answer section. If there was no delegation from
522 authoritative data, look for the best one from the cache, and put
523 it in the authority section. Go to step 6.
524
525 5. Use the local resolver or a copy of its algorithm to answer the
526 query. Store the results, including any intermediate CNAMEs and
527 DNAMEs, in the answer section of the response.
528
529 6. Using local data only, attempt to add other RRs that may be
530 useful to the additional section of the query. Exit.
531
532 Note that there will be at most one ancestor with a DNAME as
533 described in step 4 unless some zone's data is in violation of the
534 no-descendants limitation in Section 3. An implementation might take
535 advantage of this limitation by stopping the search of step 3c or
536 step 4 when a DNAME record is encountered.
537
538 3.3. Wildcards
539
540 The use of DNAME in conjunction with wildcards is discouraged
541 [RFC4592]. Thus, records of the form "*.example.com DNAME
542 example.net" SHOULD NOT be used.
543
544
545
546
547 Rose & Wijngaards Standards Track [Page 10]
548 RFC 6672 DNAME Redirection June 2012
549
550
551 The interaction between the expansion of the wildcard and the
552 redirection of the DNAME is non-deterministic. Due to the fact that
553 the processing is non-deterministic, DNSSEC validating resolvers may
554 not be able to validate a wildcarded DNAME.
555
556 A server MAY give a warning that the behavior is unspecified if such
557 a wildcarded DNAME is loaded. The server MAY refuse it, refuse to
558 load the zone, or refuse dynamic updates.
559
560 3.4. Acceptance and Intermediate Storage
561
562 Recursive caching name servers can encounter data at names below the
563 owner name of a DNAME RR, due to a change at the authoritative server
564 where data from before and after the change resides in the cache.
565 This conflict situation is a transitional phase that ends when the
566 old data times out. The caching name server can opt to store both
567 old and new data and treat each as if the other did not exist, or
568 drop the old data, or drop the longer domain name. In any approach,
569 consistency returns after the older data TTL times out.
570
571 Recursive caching name servers MUST perform CNAME synthesis on behalf
572 of clients.
573
574 If a recursive caching name server encounters a DNSSEC validated
575 DNAME RR that contradicts information already in the cache (excluding
576 CNAME records), it SHOULD cache the DNAME RR, but it MAY cache the
577 CNAME record received along with it, subject to the rules for CNAME.
578 If the DNAME RR cannot be validated via DNSSEC (i.e., not BOGUS, but
579 not able to validate), the recursive caching server SHOULD NOT cache
580 the DNAME RR but MAY cache the CNAME record received along with it,
581 subject to the rules for CNAME.
582
583 3.4.1. Resolver Algorithm
584
585 Below is the revised version of the resolver algorithm, which appears
586 in RFC 2672, Section 4.2.
587
588 1. See if the answer is in local information or can be synthesized
589 from a cached DNAME; if so, return it to the client.
590
591 2. Find the best servers to ask.
592
593 3. Send queries until one returns a response.
594
595
596
597
598
599
600
601
602 Rose & Wijngaards Standards Track [Page 11]
603 RFC 6672 DNAME Redirection June 2012
604
605
606 4. Analyze the response, either:
607
608 A. If the response answers the question or contains a name
609 error, cache the data as well as return it back to the
610 client.
611
612 B. If the response contains a better delegation to other
613 servers, cache the delegation information, and go to step 2.
614
615 C. If the response shows a CNAME and that is not the answer
616 itself, cache the CNAME, change the SNAME to the canonical
617 name in the CNAME RR, and go to step 1.
618
619 D. If the response shows a DNAME and that is not the answer
620 itself, cache the DNAME (upon successful DNSSEC validation if
621 the client is a validating resolver). If substitution of the
622 DNAME's target name for its owner name in the SNAME would
623 overflow the legal size for a domain name, return an
624 implementation-dependent error to the application; otherwise,
625 perform the substitution and go to step 1.
626
627 E. If the response shows a server failure or other bizarre
628 contents, delete the server from the SLIST and go back to
629 step 3.
630
631 4. DNAME Discussions in Other Documents
632
633 In Section 10.3 of [RFC2181], the discussion on MX and NS records
634 touches on redirection by CNAMEs, but this also holds for DNAMEs.
635
636 Section 10.3 ("MX and NS records") of [RFC2181] states:
637
638 The domain name used as the value of a NS resource record,
639 or part of the value of a MX resource record must not be
640 an alias. Not only is the specification clear on this
641 point, but using an alias in either of these positions
642 neither works as well as might be hoped, nor well fulfills
643 the ambition that may have led to this approach. This
644 domain name must have as its value one or more address
645 records. Currently those will be A records, however in
646 the future other record types giving addressing
647 information may be acceptable. It can also have other
648 RRs, but never a CNAME RR.
649
650 The DNAME RR is discussed in RFC 3363, Section 4, on A6 and DNAME.
651 The opening premise of this section is demonstrably wrong, and so the
652 conclusion based on that premise is wrong. In particular, [RFC3363]
653 deprecates the use of DNAME in the IPv6 reverse tree. Based on the
654
655
656
657 Rose & Wijngaards Standards Track [Page 12]
658 RFC 6672 DNAME Redirection June 2012
659
660
661 experience gained in the meantime, [RFC3363] is revised, dropping all
662 constraints on having DNAME RRs in these zones [RFC6434]. This would
663 greatly improve the manageability of the IPv6 reverse tree. These
664 changes are made explicit below.
665
666 In [RFC3363], the following paragraph is updated by this document,
667 and the use of DNAME RRs in the reverse tree is no longer deprecated.
668
669 The issues for DNAME in the reverse mapping tree appears to be
670 closely tied to the need to use fragmented A6 in the main tree: if
671 one is necessary, so is the other, and if one isn't necessary, the
672 other isn't either. Therefore, in moving RFC 2874 to experimental,
673 the intent of this document is that use of DNAME RRs in the reverse
674 tree be deprecated.
675
676 5. Other Issues with DNAME
677
678 There are several issues to be aware of about the use of DNAME.
679
680 5.1. Canonical Hostnames Cannot Be below DNAME Owners
681
682 The names listed as target names of MX, NS, PTR, and SRV [RFC2782]
683 records must be canonical hostnames. This means no CNAME or DNAME
684 redirection may be present during DNS lookup of the address records
685 for the host. This is discussed in RFC 2181 [RFC2181], Section 10.3,
686 and RFC 1912 [RFC1912], Section 2.4. For SRV, see RFC 2782
687 [RFC2782], page 4.
688
689 The upshot of this is that although the lookup of a PTR record can
690 involve DNAMEs, the name listed in the PTR record cannot fall under a
691 DNAME. The same holds for NS, SRV, and MX records. For example,
692 when punycode [RFC3492] alternates for a zone use DNAME, then the NS,
693 MX, SRV, and PTR records that point to that zone must use names that
694 are not aliases in their RDATA. Then, what must be done is to have
695 the domain names with DNAME substitution already applied to it as the
696 MX, NS, PTR, and SRV data. These are valid canonical hostnames.
697
698 5.2. Dynamic Update and DNAME
699
700 DNAME records can be added, changed, and removed in a zone using
701 dynamic update transactions. Adding a DNAME RR to a zone occludes
702 any domain names that may exist under the added DNAME.
703
704 If a dynamic update message attempts to add a DNAME with a given
705 owner name, but a CNAME is associated with that name, then the server
706 MUST ignore the DNAME. If a DNAME is already associated with that
707 name, then it is replaced with the new DNAME. Otherwise, add the
708 DNAME. If a CNAME is added with a given owner name, but a DNAME is
709
710
711
712 Rose & Wijngaards Standards Track [Page 13]
713 RFC 6672 DNAME Redirection June 2012
714
715
716 associated with that name, then the CNAME MUST be ignored. Similar
717 behavior occurs for dynamic updates to an owner name of a CNAME RR
718 [RFC2136].
719
720 5.3. DNSSEC and DNAME
721
722 The following subsections specify the behavior of implementations
723 that understand both DNSSEC and DNAME (synthesis).
724
725 5.3.1. Signed DNAME, Unsigned Synthesized CNAME
726
727 In any response, a signed DNAME RR indicates a non-terminal
728 redirection of the query. There might or might not be a server-
729 synthesized CNAME in the answer section; if there is, the CNAME will
730 never be signed. For a DNSSEC validator, verification of the DNAME
731 RR and then that the CNAME was properly synthesized is sufficient
732 proof.
733
734 5.3.2. DNAME Bit in NSEC Type Map
735
736 In any negative response, the NSEC or NSEC3 [RFC5155] record type
737 bitmap SHOULD be checked to see that there was no DNAME that could
738 have been applied. If the DNAME bit in the type bitmap is set and
739 the query name is a subdomain of the closest encloser that is
740 asserted, then DNAME substitution should have been done, but the
741 substitution has not been done as specified.
742
743 5.3.3. DNAME Chains as Strong as the Weakest Link
744
745 A response can contain a chain of DNAME and CNAME redirections. That
746 chain can end in a positive answer or a negative reply (no name error
747 or no data error). Each step in that chain results in resource
748 records being added to the answer or authority section of the
749 response. Only if all steps are secure can the AD (Authentic Data)
750 bit be set for the response. If one of the steps is bogus, the
751 result is bogus.
752
753 5.3.4. Validators Must Understand DNAME
754
755 Below are examples of why DNSSEC validators MUST understand DNAME.
756 In the examples, SOA records, wildcard denial NSECs, and other
757 material not under discussion have been omitted or shortened.
758
759
760
761
762
763
764
765
766
767 Rose & Wijngaards Standards Track [Page 14]
768 RFC 6672 DNAME Redirection June 2012
769
770
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
771 5.3.4.1. Invalid Name Error Response Caused by DNAME in Bitmap
772
773 ;; Header: QR AA RCODE=3(NXDOMAIN)
774 ;; OPT PSEUDOSECTION:
775 ; EDNS: version: 0, flags: do; udp: 4096
776
777 ;; Question
778 foo.bar.example.com. IN A
779 ;; Authority
780 bar.example.com. NSEC dub.example.com. A DNAME
781 bar.example.com. RRSIG NSEC [valid signature]
782
783 If this is the received response, then only by understanding that the
784 DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
785 have been redirected by the DNAME, the validator can see that it is a
786 BOGUS reply from an attacker that collated existing records from the
787 DNS to create a confusing reply.
788
789 If the DNAME bit had not been set in the NSEC record above, then the
790 answer would have validated as a correct name error response.
791
;; Header: QR AA RCODE=3(NXDOMAIN) ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; Question foo.bar.example.com. IN A ;; Authority bar.example.com. NSEC dub.example.com. A DNAME bar.example.com. RRSIG NSEC [valid signature]
;; Header: QR AA RCODE=3(NXDOMAIN) ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; Question foo.bar.example.com. IN A ;; Authority bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC bar.example.com. RRSIG NSEC [valid signature]
792 5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap
793
794 ;; Header: QR AA RCODE=3(NXDOMAIN)
795 ;; OPT PSEUDOSECTION:
796 ; EDNS: version: 0, flags: do; udp: 4096
797
798 ;; Question
799 cee.example.com. IN A
800 ;; Authority
801 bar.example.com. NSEC dub.example.com. A DNAME
802 bar.example.com. RRSIG NSEC [valid signature]
803
804 This response has the same NSEC records as the example above, but
805 with this query name (cee.example.com), the answer is validated,
806 because 'cee' does not get redirected by the DNAME at 'bar'.
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Rose & Wijngaards Standards Track [Page 15]
823 RFC 6672 DNAME Redirection June 2012
824
825
826 5.3.4.3. Response with Synthesized CNAME
827
828 ;; Header: QR AA RCODE=0(NOERROR)
829 ;; OPT PSEUDOSECTION:
830 ; EDNS: version: 0, flags: do; udp: 4096
831
832 ;; Question
833 foo.bar.example.com. IN A
834 ;; Answer
835 bar.example.com. DNAME bar.example.net.
836 bar.example.com. RRSIG DNAME [valid signature]
837 foo.bar.example.com. CNAME foo.bar.example.net.
838
839 The response shown above has the synthesized CNAME included.
840 However, the CNAME has no signature, since the server does not sign
841 online. So this response cannot be trusted. It could be altered by
842 an attacker to be foo.bar.example.com CNAME bla.bla.example. The
843 DNAME record does have its signature included, since it does not
844 change. The validator must verify the DNAME signature and then
845 recursively resolve further in order to query for the
846 foo.bar.example.net A record.
847
848 6. Examples of DNAME Use in a Zone
849
850 Below are some examples of the use of DNAME in a zone. These
851 examples are by no means exhaustive.
852
853 6.1. Organizational Renaming
854
855 If an organization with domain name FROBOZZ.EXAMPLE.NET became part
856 of an organization with domain name ACME.EXAMPLE.COM, it might ease
857 transition by placing information such as this in its old zone.
858
859 frobozz.example.net. DNAME frobozz-division.acme.example.com.
860 MX 10 mailhub.acme.example.com.
861
862 The response to an extended recursive query for
863 www.frobozz.example.net would contain, in the answer section, the
864 DNAME record shown above and the relevant RRs for www.frobozz-
865 division.acme.example.com.
866
867 If an organization wants to have aliases for names, for a different
868 spelling or language, the same example applies. Note that the MX RR
869 at the zone apex is not redirected and has to be repeated in the
870 target zone. Also note that the services at mailhub or www.frobozz-
871 division.acme.example.com. have to recognize and handle the aliases.
872
873
874
875
876
877 Rose & Wijngaards Standards Track [Page 16]
878 RFC 6672 DNAME Redirection June 2012
879
880
881 6.2. Classless Delegation of Shorter Prefixes
882
883 The classless scheme for in-addr.arpa delegation [RFC2317] can be
884 extended to prefixes shorter than 24 bits by use of the DNAME record.
885 For example, the prefix 192.0.8.0/22 can be delegated by the
886 following records.
887
888 $ORIGIN 0.192.in-addr.arpa.
889 8/22 NS ns.slash-22-holder.example.com.
890 8 DNAME 8.8/22
891 9 DNAME 9.8/22
892 10 DNAME 10.8/22
893 11 DNAME 11.8/22
894
895 A typical entry in the resulting reverse zone for some host with
896 address 192.0.9.33 might be as follows:
897
898 $ORIGIN 8/22.0.192.in-addr.arpa.
899 33.9 PTR somehost.slash-22-holder.example.com.
900
901 The advisory remarks in [RFC2317] concerning the choice of the "/"
902 character apply here as well.
903
904 6.3. Network Renumbering Support
905
906 If IPv4 network renumbering were common, maintenance of address space
907 delegation could be simplified by using DNAME records instead of NS
908 records to delegate.
909
910 $ORIGIN new-style.in-addr.arpa.
911 189.190 DNAME in-addr.example.net.
912
913 $ORIGIN in-addr.example.net.
914 188 DNAME in-addr.customer.example.com.
915
916 $ORIGIN in-addr.customer.example.
917 1 PTR www.customer.example.com
918 2 PTR mailhub.customer.example.com.
919 ; etc ...
920
921 This would allow the address space 190.189.0.0/16 assigned to the ISP
922 "example.net" to be changed without having to alter the zone data
923 describing the use of that space by the ISP and its customers.
924
925
926
927
928
929
930
931
932 Rose & Wijngaards Standards Track [Page 17]
933 RFC 6672 DNAME Redirection June 2012
934
935
936 Renumbering IPv4 networks is currently so arduous a task that
937 updating the DNS is only a small part of the labor, so this scheme
938 may have a low value. But it is hoped that in IPv6 the renumbering
939 task will be quite different, and the DNAME mechanism may play a
940 useful part.
941
942 7. IANA Considerations
943
944 The DNAME resource record type code 39 (decimal) originally was
945 registered by [RFC2672] in the DNS Resource Record (RR) Types
946 registry table at http://www.iana.org/assignments/dns-parameters.
947 IANA has updated the DNS resource record registry to point to this
948 document for RR type 39.
949
950 8. Security Considerations
951
952 DNAME redirects queries elsewhere, which may impact security based on
953 policy and the security status of the zone with the DNAME and the
954 redirection zone's security status. For validating resolvers, the
955 lowest security status of the links in the chain of CNAME and DNAME
956 redirections is applied to the result.
957
958 If a validating resolver accepts wildcarded DNAMEs, this creates
959 security issues. Since the processing of a wildcarded DNAME is non-
960 deterministic and the CNAME that was substituted by the server has no
961 signature, the resolver may choose a different result than what the
962 server meant, and consequently end up at the wrong destination. Use
963 of wildcarded DNAMEs is discouraged in any case [RFC4592].
964
965 A validating resolver MUST understand DNAME, according to [RFC4034].
966 The examples in Section 5.3.4 illustrate this need.
967
968 9. Acknowledgments
969
970 The authors of this document would like to acknowledge Matt Larson
971 for beginning this effort to address the issues related to the DNAME
972 RR type. The authors would also like to acknowledge Paul Vixie, Ed
973 Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
974 Hoenes, and Kevin Darcy for their reviews and comments on this
975 document.
976
977
978
979
980
981
982
983
984
985
986
987 Rose & Wijngaards Standards Track [Page 18]
988 RFC 6672 DNAME Redirection June 2012
989
990
991 10. References
992
993 10.1. Normative References
994
995 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
996 STD 13, RFC 1034, November 1987.
997
998 [RFC1035] Mockapetris, P., "Domain names - implementation and
999 specification", STD 13, RFC 1035, November 1987.
1000
1001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1002 Requirement Levels", BCP 14, RFC 2119, March 1997.
1003
1004 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1005 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1006 RFC 2136, April 1997.
1007
1008 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1009 Specification", RFC 2181, July 1997.
1010
1011 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
1012 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
1013
1014 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
1015 specifying the location of services (DNS SRV)", RFC 2782,
1016 February 2000.
1017
1018 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
1019 (RR) Types", RFC 3597, September 2003.
1020
1021 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1022 Rose, "DNS Security Introduction and Requirements",
1023 RFC 4033, March 2005.
1024
1025 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1026 Rose, "Resource Records for the DNS Security Extensions",
1027 RFC 4034, March 2005.
1028
1029 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1030 Rose, "Protocol Modifications for the DNS Security
1031 Extensions", RFC 4035, March 2005.
1032
1033 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
1034 System", RFC 4592, July 2006.
1035
1036 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
1037 Security (DNSSEC) Hashed Authenticated Denial of
1038 Existence", RFC 5155, March 2008.
1039
1040
1041
1042 Rose & Wijngaards Standards Track [Page 19]
1043 RFC 6672 DNAME Redirection June 2012
1044
1045
1046 10.2. Informative References
1047
1048 [RFC1912] Barr, D., "Common DNS Operational and Configuration
1049 Errors", RFC 1912, February 1996.
1050
1051 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
1052 RFC 2672, August 1999.
1053
1054 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
1055 Hain, "Representing Internet Protocol version 6 (IPv6)
1056 Addresses in the Domain Name System (DNS)", RFC 3363,
1057 August 2002.
1058
1059 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1060 for Internationalized Domain Names in Applications
1061 (IDNA)", RFC 3492, March 2003.
1062
1063 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
1064 Requirements", RFC 6434, December 2011.
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097 Rose & Wijngaards Standards Track [Page 20]
1098 RFC 6672 DNAME Redirection June 2012
1099
1100
1101 Appendix A. Changes from RFC 2672
1102
1103 A.1. Changes to Server Behavior
1104
1105 Major changes to server behavior from the original DNAME
1106 specification are summarized below:
1107
1108 o The rules for DNAME substitution have been clarified in
1109 Section 2.2.
1110
1111 o The EDNS option to signal DNAME understanding and compression has
1112 never been specified, and this document clarifies that there is no
1113 signaling method (Section 2.5).
1114
1115 o The TTL for synthesized CNAME RRs is now set to the TTL of the
1116 DNAME, not zero (Section 3.1).
1117
1118 o Recursive caching servers MUST perform CNAME synthesis on behalf
1119 of clients (Section 3.4).
1120
1121 o The revised server algorithm is detailed in Section 3.2.
1122
1123 o Rules for dynamic update messages adding a DNAME or CNAME RR to a
1124 zone where a CNAME or DNAME already exists are detailed in
1125 Section 5.2.
1126
1127 A.2. Changes to Client Behavior
1128
1129 Major changes to client behavior from the original DNAME
1130 specification are summarized below:
1131
1132 o Clients MUST be able to accept synthesized CNAME RR's with a TTL
1133 of either zero or the TTL of the DNAME RR that accompanies the
1134 CNAME RR.
1135
1136 o DNSSEC-aware clients SHOULD cache DNAME RRs and MAY cache
1137 synthesized CNAME RRs they receive in the same response. DNSSEC-
1138 aware clients SHOULD also check the NSEC/NSEC3 type bitmap to
1139 verify that DNAME redirection is to be done. DNSSEC validators
1140 MUST understand DNAME (Section 5.3).
1141
1142 o The revised client algorithm is detailed in Section 3.4.1.
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152 Rose & Wijngaards Standards Track [Page 21]
1153 RFC 6672 DNAME Redirection June 2012
1154
1155
1156 Authors' Addresses
1157
1158 Scott Rose
1159 NIST
1160 100 Bureau Dr.
1161 Gaithersburg, MD 20899
1162 USA
1163
1164 Phone: +1-301-975-8439
1165 Fax: +1-301-975-6238
1166 EMail: scott.rose@nist.gov
1167
1168
1169 Wouter Wijngaards
1170 NLnet Labs
1171 Science Park 140
1172 Amsterdam 1098 XH
1173 The Netherlands
1174
1175 Phone: +31-20-888-4551
1176 EMail: wouter@nlnetlabs.nl
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207 Rose & Wijngaards Standards Track [Page 22]
1208
;; Header: QR AA RCODE=3(NXDOMAIN) ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; Question cee.example.com. IN A ;; Authority bar.example.com. NSEC dub.example.com. A DNAME bar.example.com. RRSIG NSEC [valid signature]
;; Header: QR AA RCODE=3(NXDOMAIN) ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; Question cee.example.com. IN A ;; Authority bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC bar.example.com. RRSIG NSEC [valid signature]