7Network Working Group M. Crawford
8Request for Comments: 2672 Fermilab
9Category: Standards Track August 1999
12 Non-Terminal DNS Name Redirection
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright (C) The Internet Society (1999). All Rights Reserved.
28 This document defines a new DNS Resource Record called "DNAME", which
29 provides the capability to map an entire subtree of the DNS name
30 space to another domain. It differs from the CNAME record which maps
31 a single node of the name space.
33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
35 document are to be interpreted as described in [KWORD].
39 This Resource Record and its processing rules were conceived as a
40 solution to the problem of maintaining address-to-name mappings in a
41 context of network renumbering. Without the DNAME mechanism, an
42 authoritative DNS server for the address-to-name mappings of some
43 network must be reconfigured when that network is renumbered. With
44 DNAME, the zone can be constructed so that it needs no modification
45 when renumbered. DNAME can also be useful in other situations, such
46 as when an organizational unit is renamed.
483. The DNAME Resource Record
50 The DNAME RR has mnemonic DNAME and type code 39 (decimal).
58Crawford Standards Track [Page 1]
60RFC 2672 Non-Terminal DNS Name Redirection August 1999
63 DNAME has the following format:
65 <owner> <ttl> <class> DNAME <target>
67 The format is not class-sensitive. All fields are required. The
68 RDATA field <target> is a <domain-name> [DNSIS].
70 The DNAME RR causes type NS additional section processing.
72 The effect of the DNAME record is the substitution of the record's
73 <target> for its <owner> as a suffix of a domain name. A "no-
74 descendants" limitation governs the use of DNAMEs in a zone file:
76 If a DNAME RR is present at a node N, there may be other data at N
77 (except a CNAME or another DNAME), but there MUST be no data at
78 any descendant of N. This restriction applies only to records of
79 the same class as the DNAME record.
81 This rule assures predictable results when a DNAME record is cached
82 by a server which is not authoritative for the record's zone. It
83 MUST be enforced when authoritative zone data is loaded. Together
84 with the rules for DNS zone authority [DNSCLR] it implies that DNAME
85 and NS records can only coexist at the top of a zone which has only
88 The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
89 portion of a DNAME record unless the sending server has some way of
90 knowing that the receiver understands the DNAME record format.
91 Signalling such understanding is expected to be the subject of future
94 Naming loops can be created with DNAME records or a combination of
95 DNAME and CNAME records, just as they can with CNAME records alone.
96 Resolvers, including resolvers embedded in DNS servers, MUST limit
97 the resources they devote to any query. Implementors should note,
98 however, that fairly lengthy chains of DNAME records may be valid.
102 To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
103 must be modified slightly for both servers and resolvers.
105 Both modified algorithms incorporate the operation of making a
106 substitution on a name (either QNAME or SNAME) under control of a
107 DNAME record. This operation will be referred to as "the DNAME
114Crawford Standards Track [Page 2]
116RFC 2672 Non-Terminal DNS Name Redirection August 1999
1194.1. Processing by Servers
121 For a server performing non-recursive service steps 3.c and 4 of
122 section 4.3.2 [DNSCF] are changed to check for a DNAME record before
123 checking for a wildcard ("*") label, and to return certain DNAME
124 records from zone data and the cache.
126 DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
127 non-extended queries are presumed not to understand the semantics of
128 the DNAME record, so a server which implements this specification,
129 when answering a non-extended query, SHOULD synthesize a CNAME record
130 for each DNAME record encountered during query processing to help the
131 client reach the correct DNS data. The behavior of clients and
132 servers under Extended DNS versions greater than 0 will be specified
133 when those versions are defined.
135 The synthesized CNAME RR, if provided, MUST have
137 The same CLASS as the QCLASS of the query,
141 An <owner> equal to the QNAME in effect at the moment the DNAME RR
144 An RDATA field containing the new QNAME formed by the action of
145 the DNAME substitution.
147 If the server has the appropriate key on-line [DNSSEC, SECDYN], it
148 MAY generate and return a SIG RR for the synthesized CNAME RR.
150 The revised server algorithm is:
152 1. Set or clear the value of recursion available in the response
153 depending on whether the name server is willing to provide
154 recursive service. If recursive service is available and
155 requested via the RD bit in the query, go to step 5, otherwise
158 2. Search the available zones for the zone which is the nearest
159 ancestor to QNAME. If such a zone is found, go to step 3,
162 3. Start matching down, label by label, in the zone. The matching
163 process can terminate several ways:
170Crawford Standards Track [Page 3]
172RFC 2672 Non-Terminal DNS Name Redirection August 1999
175 a. If the whole of QNAME is matched, we have found the node.
177 If the data at the node is a CNAME, and QTYPE doesn't match
178 CNAME, copy the CNAME RR into the answer section of the
179 response, change QNAME to the canonical name in the CNAME RR,
180 and go back to step 1.
182 Otherwise, copy all RRs which match QTYPE into the answer
183 section and go to step 6.
185 b. If a match would take us out of the authoritative data, we have
186 a referral. This happens when we encounter a node with NS RRs
187 marking cuts along the bottom of a zone.
189 Copy the NS RRs for the subzone into the authority section of
190 the reply. Put whatever addresses are available into the
191 additional section, using glue RRs if the addresses are not
192 available from authoritative data or the cache. Go to step 4.
194 c. If at some label, a match is impossible (i.e., the
195 corresponding label does not exist), look to see whether the
196 last label matched has a DNAME record.
198 If a DNAME record exists at that point, copy that record into
199 the answer section. If substitution of its <target> for its
200 <owner> in QNAME would overflow the legal size for a <domain-
201 name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
202 perform the substitution and continue. If the query was not
203 extended [EDNS0] with a Version indicating understanding of the
204 DNAME record, the server SHOULD synthesize a CNAME record as
205 described above and include it in the answer section. Go back
208 If there was no DNAME record, look to see if the "*" label
211 If the "*" label does not exist, check whether the name we are
212 looking for is the original QNAME in the query or a name we
213 have followed due to a CNAME. If the name is original, set an
214 authoritative name error in the response and exit. Otherwise
217 If the "*" label does exist, match RRs at that node against
218 QTYPE. If any match, copy them into the answer section, but
219 set the owner of the RR to be QNAME, and not the node with the
220 "*" label. Go to step 6.
226Crawford Standards Track [Page 4]
228RFC 2672 Non-Terminal DNS Name Redirection August 1999
231 4. Start matching down in the cache. If QNAME is found in the cache,
232 copy all RRs attached to it that match QTYPE into the answer
233 section. If QNAME is not found in the cache but a DNAME record is
234 present at an ancestor of QNAME, copy that DNAME record into the
235 answer section. If there was no delegation from authoritative
236 data, look for the best one from the cache, and put it in the
237 authority section. Go to step 6.
239 5. Use the local resolver or a copy of its algorithm (see resolver
240 section of this memo) to answer the query. Store the results,
241 including any intermediate CNAMEs and DNAMEs, in the answer
242 section of the response.
244 6. Using local data only, attempt to add other RRs which may be
245 useful to the additional section of the query. Exit.
247 Note that there will be at most one ancestor with a DNAME as
248 described in step 4 unless some zone's data is in violation of the
249 no-descendants limitation in section 3. An implementation might take
250 advantage of this limitation by stopping the search of step 3c or
251 step 4 when a DNAME record is encountered.
2534.2. Processing by Resolvers
255 A resolver or a server providing recursive service must be modified
256 to treat a DNAME as somewhat analogous to a CNAME. The resolver
257 algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
258 as 4.e and insert a new 4.d. The complete algorithm becomes:
260 1. See if the answer is in local information, and if so return it to
263 2. Find the best servers to ask.
265 3. Send them queries until one returns a response.
267 4. Analyze the response, either:
269 a. if the response answers the question or contains a name error,
270 cache the data as well as returning it back to the client.
272 b. if the response contains a better delegation to other servers,
273 cache the delegation information, and go to step 2.
275 c. if the response shows a CNAME and that is not the answer
276 itself, cache the CNAME, change the SNAME to the canonical name
277 in the CNAME RR and go to step 1.
282Crawford Standards Track [Page 5]
284RFC 2672 Non-Terminal DNS Name Redirection August 1999
287 d. if the response shows a DNAME and that is not the answer
288 itself, cache the DNAME. If substitution of the DNAME's
289 <target> for its <owner> in the SNAME would overflow the legal
290 size for a <domain-name>, return an implementation-dependent
291 error to the application; otherwise perform the substitution
294 e. if the response shows a server failure or other bizarre
295 contents, delete the server from the SLIST and go back to step
298 A resolver or recursive server which understands DNAME records but
299 sends non-extended queries MUST augment step 4.c by deleting from the
300 reply any CNAME records which have an <owner> which is a subdomain of
301 the <owner> of any DNAME record in the response.
3055.1. Organizational Renaming
307 If an organization with domain name FROBOZZ.EXAMPLE became part of an
308 organization with domain name ACME.EXAMPLE, it might ease transition
309 by placing information such as this in its old zone.
311 frobozz.example. DNAME frobozz-division.acme.example.
312 MX 10 mailhub.acme.example.
314 The response to an extended recursive query for www.frobozz.example
315 would contain, in the answer section, the DNAME record shown above
316 and the relevant RRs for www.frobozz-division.acme.example.
3185.2. Classless Delegation of Shorter Prefixes
320 The classless scheme for in-addr.arpa delegation [INADDR] can be
321 extended to prefixes shorter than 24 bits by use of the DNAME record.
322 For example, the prefix 192.0.8.0/22 can be delegated by the
325 $ORIGIN 0.192.in-addr.arpa.
326 8/22 NS ns.slash-22-holder.example.
338Crawford Standards Track [Page 6]
340RFC 2672 Non-Terminal DNS Name Redirection August 1999
343 A typical entry in the resulting reverse zone for some host with
344 address 192.0.9.33 might be
346 $ORIGIN 8/22.0.192.in-addr.arpa.
347 33.9 PTR somehost.slash-22-holder.example.
349 The same advisory remarks concerning the choice of the "/" character
350 apply here as in [INADDR].
3525.3. Network Renumbering Support
354 If IPv4 network renumbering were common, maintenance of address space
355 delegation could be simplified by using DNAME records instead of NS
358 $ORIGIN new-style.in-addr.arpa.
359 189.190 DNAME in-addr.example.net.
361 $ORIGIN in-addr.example.net.
362 188 DNAME in-addr.customer.example.
364 $ORIGIN in-addr.customer.example.
365 1 PTR www.customer.example.
366 2 PTR mailhub.customer.example.
369 This would allow the address space 190.189.0.0/16 assigned to the ISP
370 "example.net" to be changed without the necessity of altering the
371 zone files describing the use of that space by the ISP and its
374 Renumbering IPv4 networks is currently so arduous a task that
375 updating the DNS is only a small part of the labor, so this scheme
376 may have a low value. But it is hoped that in IPv6 the renumbering
377 task will be quite different and the DNAME mechanism may play a
3806. IANA Considerations
382 This document defines a new DNS Resource Record type with the
383 mnemonic DNAME and type code 39 (decimal). The naming/numbering
384 space is defined in [DNSIS]. This name and number have already been
385 registered with the IANA.
394Crawford Standards Track [Page 7]
396RFC 2672 Non-Terminal DNS Name Redirection August 1999
3997. Security Considerations
401 The DNAME record is similar to the CNAME record with regard to the
402 consequences of insertion of a spoofed record into a DNS server or
403 resolver, differing in that the DNAME's effect covers a whole subtree
404 of the name space. The facilities of [DNSSEC] are available to
405 authenticate this record type.
409 [DNSCF] Mockapetris, P., "Domain names - concepts and facilities",
410 STD 13, RFC 1034, November 1987.
412 [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
413 Specification", RFC 2181, July 1997.
415 [DNSIS] Mockapetris, P., "Domain names - implementation and
416 specification", STD 13, RFC 1035, November 1987.
418 [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
419 Security Extensions", RFC 2065, January 1997.
421 [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
422 "Dynamic Updates in the Domain Name System", RFC 2136, April
425 [EDNS0] Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
428 [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
429 ADDR.ARPA delegation", RFC 2317, March 1998.
431 [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
432 Requirement Levels," BCP 14, RFC 2119, March 1997.
434 [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
435 Update", RFC 2137, April 1997.
445 Phone: +1 630 840-3461
446 EMail: crawdad@fnal.gov
450Crawford Standards Track [Page 8]
452RFC 2672 Non-Terminal DNS Name Redirection August 1999
45510. Full Copyright Statement
457 Copyright (C) The Internet Society (1999). All Rights Reserved.
459 This document and translations of it may be copied and furnished to
460 others, and derivative works that comment on or otherwise explain it
461 or assist in its implementation may be prepared, copied, published
462 and distributed, in whole or in part, without restriction of any
463 kind, provided that the above copyright notice and this paragraph are
464 included on all such copies and derivative works. However, this
465 document itself may not be modified in any way, such as by removing
466 the copyright notice or references to the Internet Society or other
467 Internet organizations, except as needed for the purpose of
468 developing Internet standards in which case the procedures for
469 copyrights defined in the Internet Standards process must be
470 followed, or as required to translate it into languages other than
473 The limited permissions granted above are perpetual and will not be
474 revoked by the Internet Society or its successors or assigns.
476 This document and the information contained herein is provided on an
477 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
478 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
479 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
480 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
481 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
485 Funding for the RFC Editor function is currently provided by the
506Crawford Standards Track [Page 9]