idnits 2.17.1 draft-ietf-dnsind-dname-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 21, 1999) is 9140 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2065 (ref. 'DNSSEC') (Obsoleted by RFC 2535) -- No information found for draft-dnsind-edns0 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EDNS0' ** Obsolete normative reference: RFC 2137 (ref. 'SECDYN') (Obsoleted by RFC 3007) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND Working Group Matt Crawford 2 Internet Draft Fermilab 3 March 21, 1999 5 Non-Terminal DNS Name Redirection 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress." 21 To view the list Internet-Draft Shadow Directories, see 22 http://www.ietf.org/shadow.html. 24 1. Introduction 26 This document defines a new DNS Resource Record called ``DNAME'', 27 which provides the capability to map an entire subtree of the DNS 28 name space to another domain. It differs from the CNAME record 29 which maps a single node of the name space. 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [KWORD]. 35 2. Motivation 37 This Resource Record and its processing rules were conceived as a 38 solution to the problem of maintaining address-to-name mappings in a 39 context of network renumbering. Without the DNAME mechanism, an 40 authoritative DNS server for the address-to-name mappings of some 41 network must be reconfigured when that network is renumbered. With 42 DNAME, the zone can be constructed so that it needs no modification 43 when renumbered. DNAME can also be useful in other situations, such 44 as when an organizational unit is renamed. 46 3. The DNAME Resource Record 48 The DNAME RR has mnemonic DNAME and type code 39 (decimal). 50 DNAME has the following format: 52 DNAME 54 The format is not class-sensitive. All fields are required. The 55 RDATA field is a [DNSIS]. 57 The DNAME RR causes type NS additional section processing. 59 The effect of the DNAME record is the substitution of the record's 60 for its as a suffix of a domain name. A "no- 61 descendants" limitation governs the use of DNAMEs in a zone file: 63 If a DNAME RR is present at a node N, there may be other data at 64 N (except a CNAME or another DNAME), but there MUST be no data 65 at any descendant of N. This restriction applies only to 66 records of the same class as the DNAME record. 68 This rule assures predictable results when a DNAME record is cached 69 by a server which is not authoritative for the record's zone. It 70 MUST be enforced when authoritative zone data is loaded. Together 71 with the rules for DNS zone authority [DNSCLR] it implies that DNAME 72 and NS records can only coexist at the top of a zone which has only 73 one node. 75 The compression scheme of [DNSIS] MUST NOT be applied to the RDATA 76 portion of a DNAME record unless the sending server has some way of 77 knowing that the receiver understands the DNAME record format. 78 Signalling such understanding is expected to be the subject of 79 future DNS Extensions. 81 Naming loops can be created with DNAME records or a combination of 82 DNAME and CNAME records, just as they can with CNAME records alone. 83 Resolvers, including resolvers embedded in DNS servers, MUST limit 84 the resources they devote to any query. Implementors should note, 85 however, that fairly lengthy chains of DNAME records may be valid. 87 4. Query Processing 89 To exploit the DNAME mechanism the name resolution algorithms 90 [DNSCF] must be modified slightly for both servers and resolvers. 92 Both modified algorithms incorporate the operation of making a 93 substitution on a name (either QNAME or SNAME) under control of a 94 DNAME record. This operation will be referred to as "the DNAME 95 substitution". 97 4.1. Processing by Servers 99 For a server performing non-recursive service steps 3.c and 4 of 100 section 4.3.2 [DNSCF] are changed to check for a DNAME record before 101 checking for a wildcard ("*") label, and to return certain DNAME 102 records from zone data and the cache. 104 DNS clients sending Extended DNS [EDNS0] queries with Version 0 or 105 non-extended queries are presumed not to understand the semantics of 106 the DNAME record, so a server which implements this specification, 107 when answering a non-extended query, SHOULD synthesize a CNAME 108 record for each DNAME record encountered during query processing to 109 help the client reach the correct DNS data. The behavior of clients 110 and servers under Extended DNS versions greater than 0 will be 111 specified when those versions are defined. 113 The synthesized CNAME RR, if provided, MUST have 115 The same CLASS as the QCLASS of the query, 117 TTL equal to zero, 119 An equal to the QNAME in effect at the moment the DNAME 120 RR was encountered, and 122 An RDATA field containing the new QNAME formed by the action of 123 the DNAME substitution. 125 If the server has the appropriate key on-line [DNSSEC, SECDYN], it 126 MAY generate and return a SIG RR for the synthesized CNAME RR. 128 The revised server algorithm is: 130 1. Set or clear the value of recursion available in the response 131 depending on whether the name server is willing to provide 132 recursive service. If recursive service is available and 133 requested via the RD bit in the query, go to step 5, otherwise 134 step 2. 136 2. Search the available zones for the zone which is the nearest 137 ancestor to QNAME. If such a zone is found, go to step 3, 138 otherwise step 4. 140 3. Start matching down, label by label, in the zone. The matching 141 process can terminate several ways: 143 a. If the whole of QNAME is matched, we have found the node. 145 If the data at the node is a CNAME, and QTYPE doesn't match 146 CNAME, copy the CNAME RR into the answer section of the 147 response, change QNAME to the canonical name in the CNAME 148 RR, and go back to step 1. 150 Otherwise, copy all RRs which match QTYPE into the answer 151 section and go to step 6. 153 b. If a match would take us out of the authoritative data, we 154 have a referral. This happens when we encounter a node with 155 NS RRs marking cuts along the bottom of a zone. 157 Copy the NS RRs for the subzone into the authority section 158 of the reply. Put whatever addresses are available into the 159 additional section, using glue RRs if the addresses are not 160 available from authoritative data or the cache. Go to step 161 4. 163 c. If at some label, a match is impossible (i.e., the 164 corresponding label does not exist), look to see whether the 165 last label matched has a DNAME record. 167 If a DNAME record exists at that point, copy that record 168 into the answer section. If substitution of its 169 for its in QNAME would overflow the legal size for a 170 , set RCODE to YXDOMAIN [DNSUPD] and exit; 171 otherwise perform the substitution and continue. If the 172 query was not extended [EDNS0] with a Version indicating 173 understanding of the DNAME record, the server SHOULD 174 synthesize a CNAME record as described above and include it 175 in the answer section. Go back to step 1. 177 If there was no DNAME record, look to see if the "*" label 178 exists. 180 If the "*" label does not exist, check whether the name we 181 are looking for is the original QNAME in the query or a name 182 we have followed due to a CNAME. If the name is original, 183 set an authoritative name error in the response and exit. 184 Otherwise just exit. 186 If the "*" label does exist, match RRs at that node against 187 QTYPE. If any match, copy them into the answer section, but 188 set the owner of the RR to be QNAME, and not the node with 189 the "*" label. Go to step 6. 191 4. Start matching down in the cache. If QNAME is found in the 192 cache, copy all RRs attached to it that match QTYPE into the 193 answer section. If QNAME is not found in the cache but a DNAME 194 record is present at an ancestor of QNAME, copy that DNAME 195 record into the answer section. If there was no delegation from 196 authoritative data, look for the best one from the cache, and 197 put it in the authority section. Go to step 6. 199 5. Use the local resolver or a copy of its algorithm (see resolver 200 section of this memo) to answer the query. Store the results, 201 including any intermediate CNAMEs and DNAMEs, in the answer 202 section of the response. 204 6. Using local data only, attempt to add other RRs which may be 205 useful to the additional section of the query. Exit. 207 Note that there will be at most one ancestor with a DNAME as 208 described in step 4 unless some zone's data is in violation of the 209 no-descendants limitation in section 3. An implementation might 210 take advantage of this limitation by stopping the search of step 3c 211 or step 4 when a DNAME record is encountered. 213 4.2. Processing by Resolvers 215 A resolver or a server providing recursive service must be modified 216 to treat a DNAME as somewhat analogous to a CNAME. The resolver 217 algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d 218 as 4.e and insert a new 4.d. The complete algorithm becomes: 220 1. See if the answer is in local information, and if so return it 221 to the client. 223 2. Find the best servers to ask. 225 3. Send them queries until one returns a response. 227 4. Analyze the response, either: 229 a. if the response answers the question or contains a name 230 error, cache the data as well as returning it back to the 231 client. 233 b. if the response contains a better delegation to other 234 servers, cache the delegation information, and go to step 2. 236 c. if the response shows a CNAME and that is not the answer 237 itself, cache the CNAME, change the SNAME to the canonical 238 name in the CNAME RR and go to step 1. 240 d. if the response shows a DNAME and that is not the answer 241 itself, cache the DNAME. If substitution of the DNAME's 242 for its in the SNAME would overflow the 243 legal size for a , return an implementation- 244 dependent error to the application; otherwise perform the 245 substitution and go to step 1. 247 e. if the response shows a server failure or other bizarre 248 contents, delete the server from the SLIST and go back to 249 step 3. 251 A resolver or recursive server which understands DNAME records but 252 sends non-extended queries MUST augment step 4.c by deleting from 253 the reply any CNAME records which have an which is a 254 subdomain of the of any DNAME record in the response. 256 5. Examples of Use 258 5.1. Organizational Renaming 260 If an organization with domain name FROBOZZ.EXAMPLE became part of 261 an organization with domain name ACME.EXAMPLE, it might ease 262 transition by placing information such as this in its old zone. 264 frobozz.example. DNAME frobozz-division.acme.example. 265 MX 10 mailhub.acme.example. 267 The response to an extended recursive query for www.frobozz.example 268 would contain, in the answer section, the DNAME record shown above 269 and the relevant RRs for www.frobozz-division.acme.example. 271 5.2. Classless Delegation of Shorter Prefixes 273 The classless scheme for in-addr.arpa delegation [INADDR] can be 274 extended to prefixes shorter than 24 bits by use of the DNAME 275 record. For example, the prefix 192.0.8.0/22 can be delegated by 276 the following records. 278 $ORIGIN 0.192.in-addr.arpa. 279 8/22 NS ns.slash-22-holder.example. 280 8 DNAME 8.8/22 281 9 DNAME 9.8/22 282 10 DNAME 10.8/22 283 11 DNAME 11.8/22 285 A typical entry in the resulting reverse zone for some host with 286 address 192.0.9.33 might be 288 $ORIGIN 8/22.0.192.in-addr.arpa. 289 33.9 PTR somehost.slash-22-holder.example. 291 The same advisory remarks concerning the choice of the "/" character 292 apply here as in [INADDR]. 294 5.3. Network Renumbering Support 296 If IPv4 network renumbering were common, maintenance of address 297 space delegation could be simplified by using DNAME records instead 298 of NS records to delegate. 300 $ORIGIN new-style.in-addr.arpa. 301 189.190 DNAME in-addr.example.net. 303 $ORIGIN in-addr.example.net. 304 188 DNAME in-addr.customer.example. 306 $ORIGIN in-addr.customer.example. 307 1 PTR www.customer.example. 308 2 PTR mailhub.customer.example. 309 ; etc ... 311 This would allow the address space 190.189.0.0/16 assigned to the 312 ISP "example.net" to be changed without the necessity of altering 313 the zone files describing the use of that space by the ISP and its 314 customers. 316 Renumbering IPv4 networks is currently so arduous a task that 317 updating the DNS is only a small part of the labor, so this scheme 318 may have a low value. But it is hoped that in IPv6 the renumbering 319 task will be quite different and the DNAME mechanism may play a 320 useful part. 322 6. IANA Considerations 324 This document defines a new DNS Resource Record type with the 325 mnemonic DNAME and type code 39 (decimal). The naming/numbering 326 space is defined in [DNSIS]. This name and number have already been 327 registered with the IANA. 329 7. Security Considerations 331 The DNAME record is similar to the CNAME record with regard to the 332 consequences of insertion of a spoofed record into a DNS server or 333 resolver, differing in that the DNAME's effect covers a whole 334 subtree of the name space. The facilities of [DNSSEC] are available 335 to authenticate this record type. 337 8. References 339 [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", 340 RFC 1034. 342 [DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification", 343 RFC 2181. 345 [DNSIS] P.V. Mockapetris, "Domain names - implementation and 346 specification", RFC 1035. 348 [DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security 349 Extensions", RFC 2065. 351 [DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic 352 Updates in the Domain Name System", RFC 2136. 354 [EDNS0] P. Vixie, "Extensions mechanisms for DNS (EDNS0)", Currently 355 draft-dnsind-edns0-01.txt. 357 [INADDR] H. Eidnes, G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA 358 delegation", RFC 2317. 360 [KWORD] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels," RFC 2119. 363 [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic 364 Update", RFC 2137. 366 9. Author's Address 368 Matt Crawford 369 Fermilab MS 368 370 PO Box 500 371 Batavia, IL 60510 372 USA 374 Phone: +1 630 840-3461 376 EMail: crawdad@fnal.gov