idnits 2.17.1 draft-ietf-dnsind-dname-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (July 24, 1998) is 9408 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) == Missing Reference: 'SECDYN' is mentioned on line 157, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-dnsind-binary-labels-02 ** Downref: Normative reference to an Historic draft: draft-ietf-dnsind-binary-labels (ref. 'BITLBL') ** Obsolete normative reference: RFC 2065 (ref. 'DNSSEC') (Obsoleted by RFC 2535) -- No information found for draft-dnsind-edns - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EDNS' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Matt Crawford 3 Internet Draft Fermilab 4 July 24, 1998 6 Non-Terminal DNS Name Redirection 7 9 Status of this Memo 11 This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (North 25 Europe), ftp.nis.garr.it (South Europe), ftp.ietf.org (US East 26 Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 Distribution of this memo is unlimited. 30 1. Introduction 32 This document defines a new DNS Resource Record called ``DNAME'', 33 which provides the capability to map an entire subtree of the DNS 34 name space to another domain. It differs from the CNAME record 35 which maps a single node of the name space. 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [KWORD]. 41 2. Motivation 43 This Resource Record and its processing rules were conceived as a 44 solution to the problem of maintaining address-to-name mappings in a 45 context of network renumbering. Without the DNAME mechanism, an 46 authoritative DNS server for the address-to-name mappings of some 47 network must be reconfigured when that network is renumbered. With 48 DNAME, the zone can be constructed so that it needs no modification 49 when renumbered. DNAME can also be useful in other situations, such 50 as when an organizational unit is renamed. 52 3. The DNAME Resource Record 54 The DNAME RR has mnemonic DNAME and type code TBA (decimal). 56 DNAME has the following format: 58 DNAME 60 The format is not class-sensitive. All fields are required. The 61 RDATA field is a [DNSIS]. 63 The DNAME RR causes type NS additional section processing. 65 The effect of the DNAME record is the substitution of the record's 66 for its as a suffix of a domain name. Two limiting 67 rules govern the use of DNAMEs. 69 Rule One 70 If a DNAME RR is present at a node N, there may be other data at N 71 (except a CNAME or another DNAME), but there MUST be no data at 72 any descendant of N. This restriction applies only to records of 73 the same class as the DNAME record. 75 Rule Two 76 When resolving a query, it is valid to encounter more than one 77 DNAME record along the way ONLY IF every DNAME record encountered 78 has fewer labels in its than in its . (Note that 79 in the bit-string label [BITLBL], each bit is a separate label.) 80 If a single DNAME is encountered this document places no new 81 restriction on the number of labels in its . 83 Rule One assures predictable results when a DNAME record is cached 84 by a server which is not authoritative for the record's zone. It 85 MUST be enforced when authoritative zone data is loaded. This rule, 86 together with the rules for DNS zone authority [DNSCLR] imply that 87 DNAME and NS records can only coexist at the top of a zone which has 88 only one node. 90 Rule Two prevents DNAME loops. It MUST be enforced by servers 91 during recursive query processing and by resolvers. 93 4. Query Processing 95 To exploit the DNAME mechanism the name resolution algorithms 96 [DNSCF] must be modified slightly for both servers and resolvers. 97 In both cases a conceptual per-query variable DFLAG is introduced to 98 enforce Rule Two. Implementations MAY use other means to enforce 99 the rule. DFLAG's value is 101 0 when processing of a query begins and whenever no DNAME has been 102 encountered; 104 1 when one or more DNAME records have been encountered, and each 105 had fewer labels in its than in its ; 107 2 when a DNAME record has been encountered which had at least as 108 many labels in its as in its . 110 Both modified algorithms incorporate the operation of making a 111 substitution on a name (either QNAME or SNAME) under control of a 112 DNAME record. For conciseness, this operation is elaborated here 113 and will be referred to as "Procedure S". 115 S1. If DFLAG = 2, Rule Two is violated. Go to step S4. 117 S2. If DFLAG = 1 and the DNAME record's does not have fewer 118 labels than its , Rule Two is violated. Go to step S4. 120 S3. If substituting the DNAME's for its in the name 121 being operated on would overflow the legal size for a , go to step S4. Otherwise make the substitution. 124 If the has fewer labels than the , set DFLAG to 125 1, otherwise set DFLAG to 2. Return. 127 S4. In a resolver, return an implementation-dependent error to the 128 application. In a server, copy the DNAME record to the answer 129 section, set RCODE to YXDOMAIN [DNSUPD], and exit. 131 4.1. Processing by Servers 133 For a server performing non-recursive service steps 3.c and 4 of 134 section 4.3.2 [DNSCF] are changed to check for a DNAME record before 135 checking for a wildcard ("*") label, and to return certain DNAME 136 records from the cache. 138 DNS clients sending Extended DNS [EDNS] queries with Version 0 or 139 greater are presumed to understand the semantics of the DNAME 140 record. The sender of a non-extended query may not understand 141 DNAME, so a server which implements this specification, when 142 answering a non-extended query, SHOULD synthesize a CNAME record for 143 each DNAME record encountered during query processing to help the 144 client reach the correct DNS data. The synthesized CNAME RR, if 145 provided, MUST have 147 The same CLASS as the QCLASS of the query, 149 TTL equal to zero, 151 An equal to the QNAME in effect at the moment the DNAME 152 RR was encountered, and 154 An RDATA field containing the new QNAME formed by the action of 155 Procedure S. 157 If the server has the appropriate key on-line [DNSSEC, SECDYN], it 158 MAY generate and return a SIG RR for the synthesized CNAME RR. 160 The revised server algorithm is: 162 1. Set or clear the value of recursion available in the response 163 depending on whether the name server is willing to provide 164 recursive service. If recursive service is available and 165 requested via the RD bit in the query, go to step 5, otherwise 166 step 2. 168 2. Search the available zones for the zone which is the nearest 169 ancestor to QNAME. If such a zone is found, go to step 3, 170 otherwise step 4. 172 3. Start matching down, label by label, in the zone. The matching 173 process can terminate several ways: 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 180 RR, 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 186 have a referral. This happens when we encounter a node with 187 NS RRs marking cuts along the bottom of a zone. 189 Copy the NS RRs for the subzone into the authority section 190 of 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 193 4. 195 c. If at some label, a match is impossible (i.e., the 196 corresponding label does not exist), look to see whether the 197 last label matched has a DNAME record. 199 If a DNAME record exists at that point, copy that record 200 into the answer section, substitute its for its 201 in QNAME according to Procedure S. If the query was 202 not extended [EDNS], the server SHOULD synthesize a CNAME 203 record as described above and include it in the answer 204 section. Go back to step 1. 206 If there was no DNAME record, look to see if the "*" label 207 exists. 209 If the "*" label does not exist, check whether the name we 210 are looking for is the original QNAME in the query or a name 211 we have followed due to a CNAME. If the name is original, 212 set an authoritative name error in the response and exit. 213 Otherwise just exit. 215 If the "*" label does exist, match RRs at that node against 216 QTYPE. If any match, copy them into the answer section, but 217 set the owner of the RR to be QNAME, and not the node with 218 the "*" label. Go to step 6. 220 4. Start matching down in the cache. If QNAME is found in the 221 cache, copy all RRs attached to it that match QTYPE into the 222 answer section. If QNAME is not found in the cache but a DNAME 223 record is present at an ancestor of QNAME, copy that DNAME 224 record into the answer section. If there was no delegation from 225 authoritative data, look for the best one from the cache, and 226 put it in the authority section. Go to step 6. 228 5. Using the local resolver or a copy of its algorithm (see 229 resolver section of this memo) to answer the query. Store the 230 results, including any intermediate CNAMEs and DNAMEs, in the 231 answer section of the response. 233 6. Using local data only, attempt to add other RRs which may be 234 useful to the additional section of the query. Exit. 236 Note that there will be at most one ancestor with a DNAME as 237 described in step 4 unless some zone's data is in violation of Rule 238 One. 240 4.2. Processing by Resolvers 242 A resolver or a server providing recursive service must be modified 243 to treat a DNAME as somewhat analogous to a CNAME. The resolver 244 algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d 245 as 4.e and insert a new 4.d. The complete algorithm becomes: 247 1. See if the answer is in local information, and if so return it 248 to the client. 250 2. Find the best servers to ask. 252 3. Send them queries until one returns a response. 254 4. Analyze the response, either: 256 a. if the response answers the question or contains a name 257 error, cache the data as well as returning it back to the 258 client. 260 b. if the response contains a better delegation to other 261 servers, cache the delegation information, and go to step 2. 263 c. if the response shows a CNAME and that is not the answer 264 itself, cache the CNAME, change the SNAME to the canonical 265 name in the CNAME RR and go to step 1. 267 d. if the response shows a DNAME the DNAME, substitute the 268 DNAME's for its in the SNAME according to 269 Procedure S and go to step 1. 271 e. if the response shows a server failure or other bizarre 272 contents, delete the server from the SLIST and go back to 273 step 3. 275 A resolver or recursive server which understands DNAME records but 276 sends non-extended queries MUST augment step 4.c by deleting from 277 the reply any CNAME records which have an which is a 278 subdomain of the of any DNAME record in the response. 280 5. Examples of Use 282 If an organization with domain name FROBOZZ.EXAMPLE became part of 283 an organization with domain name ACME.EXAMPLE, it might ease 284 transition by placing information such as this in its old zone. 286 frobozz.example. DNAME frobozz-division.acme.example. 287 MX mailhub.acme.example. 289 The response to an extended recursive query for www.frobozz.example 290 would contain, in the answer section, the DNAME record shown above 291 and the relevant RRs for www.frobozz-division.acme.example. 293 If IPv4 network renumbering were common, maintenance of address 294 space delegation could be simplified by using DNAME records instead 295 of NS records to delegate. 297 $ORIGIN new-style.in-addr.arpa. 298 189.190 DNAME in-addr.example.net. 300 $ORIGIN in-addr.example.net. 301 188 DNAME in-addr.customer.xy. 303 $ORIGIN in-addr.customer.xy. 304 1 PTR www.customer.xy. 305 2 PTR mailhub.customer.xy. 306 ; etc ... 308 This would allow the address space assigned to the ISP "example.net" 309 to be changed without the necessity of altering the zone files 310 describing the use of that space by the ISP and its customers. 312 6. References 314 [BITLBL] M. Crawford, "Binary Labels in the Domain Name System", 315 currently draft-ietf-dnsind-binary-labels-02.txt. 317 [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", 318 RFC 1034. 320 [DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification", 321 RFC 2181. 323 [DNSIS] P.V. Mockapetris, "Domain names - implementation and 324 specification", RFC 1035. 326 [DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security 327 Extensions", RFC 2065. 329 [DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic 330 Updates in the Domain Name System", RFC 2136. 332 [EDNS] P. Vixie, "Extensions to DNS (EDNS)", Currently draft- 333 dnsind-edns-02.txt. 335 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 336 Requirement Levels," RFC 2119. 338 [SECDYN]D. Eastlake, 3rd, "Secure Domain Name System Dynamic 339 Update", RFC 2137. 341 7. Author's Address 343 Matt Crawford 344 Fermilab MS 368 345 PO Box 500 346 Batavia, IL 60510 347 USA 349 Phone: +1 630 840-3461 351 EMail: crawdad@fnal.gov