idnits 2.17.1 draft-ietf-dnsext-rfc2672bis-dname-26.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2672, but the abstract doesn't seem to directly say this. It does mention RFC2672 though, so this could be OK. -- The draft header indicates that this document updates RFC3363, but the abstract doesn't seem to directly say this. It does mention RFC3363 though, so this could be OK. -- The draft header indicates that this document updates RFC4294, but the abstract doesn't seem to directly say this. It does mention RFC4294 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC3363, updated by this document, for RFC5378 checks: 2001-09-27) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 19, 2012) is 4389 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) -- Looks like a reference, but probably isn't: '0' on line 230 -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group S. Rose 3 Internet-Draft NIST 4 Obsoletes: 2672 (if approved) W. Wijngaards 5 Updates: 3363,4294 (if approved) NLnet Labs 6 Intended status: Standards Track April 19, 2012 7 Expires: October 21, 2012 9 DNAME Redirection in the DNS 10 draft-ietf-dnsext-rfc2672bis-dname-26 12 Abstract 14 The DNAME record provides redirection for a sub-tree of the domain 15 name tree in the DNS system. That is, all names that end with a 16 particular suffix are redirected to another part of the DNS. This is 17 a revision to the original specification in RFC 2672 (which this 18 document obsoletes) as well as updating RFC 3363 and RFC 4294 to 19 align with this revision. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in RFC 26 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 21, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 5 77 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 6 79 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 8 80 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 8 81 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 8 83 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 9 85 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 10 86 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 12 87 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 12 88 3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 12 90 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 13 92 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 15 93 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 15 94 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 15 95 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 15 96 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 15 97 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 16 98 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 16 99 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 16 100 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 16 101 5.3.4.2. Valid Name Error Response Involving DNAME in 102 Bitmap . . . . . . . . . . . . . . . . . . . . . . 17 103 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 17 105 6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 17 106 6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 17 107 6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 18 108 6.3. Network Renumbering Support . . . . . . . . . . . . . . . 18 110 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 114 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 117 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 118 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 120 Appendix A. Changes from RFC 2672 . . . . . . . . . . . . . . . . 21 121 A.1. Changes to Server Behavior . . . . . . . . . . . . . . . . 21 122 A.2. Changes to Client Behavior . . . . . . . . . . . . . . . . 22 124 1. Introduction 126 DNAME is a DNS Resource Record type originally defined in RFC 2672 127 [RFC2672]. DNAME provides redirection from a part of the DNS name 128 tree to another part of the DNS name tree. 130 The DNAME RR and the CNAME RR [RFC1034] cause a lookup to 131 (potentially) return data corresponding to a domain name different 132 from the queried domain name. The difference between the two 133 resource records is that the CNAME RR directs the lookup of data at 134 its owner to another single name, a DNAME RR directs lookups for data 135 at descendants of its owner's name to corresponding names under a 136 different (single) node of the tree. 138 Take for example, looking through a zone (see RFC 1034 [RFC1034], 139 section 4.3.2, step 3) for the domain name "foo.example.com" and a 140 DNAME resource record is found at "example.com" indicating that all 141 queries under "example.com" be directed to "example.net". The lookup 142 process will return to step 1 with the new query name of 143 "foo.example.net". Had the query name been "www.foo.example.com" the 144 new query name would be "www.foo.example.net". 146 This document is a revision of the original specification of DNAME in 147 RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of 148 maintaining address-to-name mappings in a context of network 149 renumbering. With a careful set-up, a renumbering event in the 150 network causes no change to the authoritative server that has the 151 address-to-name mappings. Examples in practice are classless reverse 152 address space delegations. 154 Another usage of DNAME lies in aliasing of name spaces. For example, 155 a zone administrator may want sub-trees of the DNS to contain the 156 same information. Examples include punycode [RFC3492] alternates for 157 domain spaces. 159 This revision of the DNAME specification does not change the wire 160 format or the handling of DNAME Resource Records. Discussion is 161 added on problems that may be encountered when using DNAME. 163 2. The DNAME Resource Record 165 2.1. Format 167 The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is 168 CLASS-insensitive. 170 Its RDATA is comprised of a single field, , which contains a 171 fully qualified domain name that MUST be sent in uncompressed form 172 [RFC1035], [RFC3597]. The field MUST be present. The 173 presentation format of is that of a domain name [RFC1035]. 175 DNAME 177 The effect of the DNAME RR is the substitution of the record's 178 for its owner name, as a suffix of a domain name. This 179 substitution is to be applied for all names below the owner name of 180 the DNAME RR. This substitution has to be applied for every DNAME RR 181 found in the resolution process, which allows fairly lengthy valid 182 chains of DNAME RRs. 184 Details of the substitution process, methods to avoid conflicting 185 resource records, and rules for specific corner cases are given in 186 the following subsections. 188 2.2. The DNAME Substitution 190 When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third 191 step, "start matching down, label by label, in the zone" and a node 192 is found to own a DNAME resource record a DNAME substitution occurs. 193 The name being sought may be the original query name or a name that 194 is the result of a CNAME resource record being followed or a 195 previously encountered DNAME. As in the case when finding a CNAME 196 resource record or NS resource record set, the processing of a DNAME 197 will happen prior to finding the desired domain name. 199 A DNAME substitution is performed by replacing the suffix labels of 200 the name being sought matching the owner name of the DNAME resource 201 record with the string of labels in the RDATA field. The matching 202 labels end with the root label in all cases. Only whole labels are 203 replaced. See the table of examples for common cases and corner 204 cases. 206 In the table below, the QNAME refers to the query name. The owner is 207 the DNAME owner domain name, and the target refers to the target of 208 the DNAME record. The result is the resulting name after performing 209 the DNAME substitution on the query name. "no match" means that the 210 query did not match the DNAME and thus no substitution is performed 211 and a possible error message is returned (if no other result is 212 possible). Thus every line contains one example substitution. In 213 the examples below, 'cyc' and 'shortloop' contain loops. 215 QNAME owner DNAME target result 216 ---------------- -------------- -------------- ----------------- 217 com. example.com. example.net. 218 example.com. example.com. example.net. [0] 219 a.example.com. example.com. example.net. a.example.net. 220 a.b.example.com. example.com. example.net. a.b.example.net. 221 ab.example.com. b.example.com. example.net. 222 foo.example.com. example.com. example.net. foo.example.net. 223 a.x.example.com. x.example.com. example.net. a.example.net. 224 a.example.com. example.com. y.example.net. a.y.example.net. 225 cyc.example.com. example.com. example.com. cyc.example.com. 226 cyc.example.com. example.com. c.example.com. cyc.c.example.com. 227 shortloop.x.x. x. . shortloop.x. 228 shortloop.x. x. . shortloop. 230 [0] The result depends on the QTYPE. If the QTYPE = DNAME, then 231 the result is "example.com." else "" 233 Table 1. DNAME Substitution Examples. 235 It is possible for DNAMEs to form loops, just as CNAMEs can form 236 loops. DNAMEs and CNAMEs can chain together to form loops. A single 237 corner case DNAME can form a loop. Resolvers and servers should be 238 cautious in devoting resources to a query, but be aware that fairly 239 long chains of DNAMEs may be valid. Zone content administrators 240 should take care to insure that there are no loops that could occur 241 when using DNAME or DNAME/CNAME redirection. 243 The domain name can get too long during substitution. For example, 244 suppose the target name of the DNAME RR is 250 octets in length 245 (multiple labels), if an incoming QNAME that has a first label over 5 246 octets in length, the result would be a name over 255 octets. If 247 this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The 248 DNAME record and its signature (if the zone is signed) are included 249 in the answer as proof for the YXDOMAIN (value 6) RCODE. 251 2.3. DNAME Owner Name Matching the QNAME 253 Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its 254 owner name; the owner name of a DNAME is not redirected itself. The 255 domain name that owns a DNAME record is allowed to have other 256 resource record types at that domain name, except DNAMEs, CNAMEs or 257 other types that have restrictions on what they can co-exist with. 258 When there is a match of the QTYPE to a type (or types) also owned by 259 the owner name the response is sourced from the owner name. E.g., a 260 QTYPE of ANY would return the (available) types at the owner name, 261 not the target name. 263 DNAME RRs MUST NOT appear at the same owner name as an NS RR unless 264 the owner name is the zone apex as this would constitute data below a 265 zone cut. 267 If a DNAME record is present at the zone apex, there is still a need 268 to have the customary SOA and NS resource records there as well. 269 Such a DNAME cannot be used to mirror a zone completely, as it does 270 not mirror the zone apex. 272 These rules also allow DNAME records to be queried through RFC 1034 273 [RFC1034] compliant, DNAME-unaware caches. 275 2.4. Names Next to and Below a DNAME Record 277 Resource records MUST NOT exist at any sub-domain of the owner of a 278 DNAME RR. To get the contents for names subordinate to that owner 279 name, the DNAME redirection must be invoked and the resulting target 280 queried. A server MAY refuse to load a zone that has data at a sub- 281 domain of a domain name owning a DNAME RR. If the server does load 282 the zone, those names below the DNAME RR will be occluded as 283 described in RFC 2136 [RFC2136], section 7.18. Also a server ought 284 to refuse to load a zone subordinate to the owner of a DNAME record 285 in the ancestor zone. See Section 5.2 for further discussion related 286 to dynamic update. 288 DNAME is a singleton type, meaning only one DNAME is allowed per 289 name. The owner name of a DNAME can only have one DNAME RR, and no 290 CNAME RRs can exist at that name. These rules make sure that for a 291 single domain name only one redirection exists, and thus no confusion 292 which one to follow. A server ought to refuse to load a zone that 293 violates these rules. 295 2.5. Compression of the DNAME record. 297 The DNAME owner name can be compressed like any other owner name. 298 The DNAME RDATA target name MUST NOT be sent out in compressed form 299 and MUST be downcased for DNSSEC validation. 301 Although the previous DNAME specification [RFC2672] (that is 302 obsoleted by this specification) talked about signaling to allow 303 compression of the target name, such signaling has never been 304 specified and this document also does not specify this signaling 305 behavior. 307 RFC 2672 (obsoleted by this document) stated that the EDNS version 308 had a meaning for understanding of DNAME and DNAME target name 309 compression. This document revises RFC 2672, in that there is no 310 EDNS version signaling for DNAME. 312 3. Processing 314 3.1. CNAME synthesis 316 When preparing a response, a server performing a DNAME substitution 317 will in all cases include the relevant DNAME RR in the answer 318 section. Relevant cases includes the following: 320 1. The DNAME is being employed as a substitution instruction. 322 2. The DNAME itself matches the QTYPE and the owner name matches 323 QNAME. 325 When the owner name name matches the QNAME and the QTYPE matches 326 another type owned there, the DNAME is not included in the answer. 328 A CNAME RR with TTL equal to the corresponding DNAME RR is 329 synthesized and included in the answer section when the DNAME is 330 employed as a substitution instruction. The owner name of the CNAME 331 is the QNAME of the query. The DNSSEC specification [RFC4033], 332 [RFC4034], [RFC4035] says that the synthesized CNAME does not have to 333 be signed. The signed DNAME has an RRSIG and a validating resolver 334 can check the CNAME against the DNAME record and validate the 335 signature over the DNAME RR. 337 Servers MUST be able to answer a query for a synthesized CNAME. Like 338 other query types this invokes the DNAME, and then the server 339 synthesizes the CNAME and places it into the answer section. If the 340 server in question is a cache, the synthesized CNAME's TTL SHOULD be 341 equal to the decremented TTL of the cached DNAME. 343 Resolvers MUST be able to handle a synthesized CNAME TTL of zero or 344 equal to the TTL of the corresponding DNAME record (as some older 345 authoritative server implementations set the TTL of synthesized 346 CNAMEs to zero). A TTL of zero means that the CNAME can be discarded 347 immediately after processing the answer. 349 3.2. Server algorithm 351 Below is the server algorithm, which appeared in RFC 2672 Section 352 4.1. 354 1. Set or clear the value of recursion available in the response 355 depending on whether the name server is willing to provide 356 recursive service. If recursive service is available and 357 requested via the RD bit in the query, go to step 5, otherwise 358 step 2. 360 2. Search the available zones for the zone which is the nearest 361 ancestor to QNAME. If such a zone is found, go to step 3, 362 otherwise step 4. 364 3. Start matching down, label by label, in the zone. The matching 365 process can terminate several ways: 367 A. If the whole of QNAME is matched, we have found the node. 369 If the data at the node is a CNAME, and QTYPE does not match 370 CNAME, copy the CNAME RR into the answer section of the 371 response, change QNAME to the canonical name in the CNAME RR, 372 and go back to step 1. 374 Otherwise, copy all RRs which match QTYPE into the answer 375 section and go to step 6. 377 B. If a match would take us out of the authoritative data, we 378 have a referral. This happens when we encounter a node with 379 NS RRs marking cuts along the bottom of a zone. 381 Copy the NS RRs for the sub-zone into the authority section 382 of the reply. Put whatever addresses are available into the 383 additional section, using glue RRs if the addresses are not 384 available from authoritative data or the cache. Go to step 385 4. 387 C. If at some label, a match is impossible (i.e., the 388 corresponding label does not exist), look to see whether the 389 last label matched has a DNAME record. 391 If a DNAME record exists at that point, copy that record into 392 the answer section. If substitution of its for its 393 in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise 395 perform the substitution and continue. The server MUST 396 synthesize a CNAME record as described above and include it 397 in the answer section. Go back to step 1. 399 If there was no DNAME record, look to see if the "*" label 400 exists. 402 If the "*" label does not exist, check whether the name we 403 are looking for is the original QNAME in the query or a name 404 we have followed due to a CNAME or DNAME. If the name is 405 original, set an authoritative name error in the response and 406 exit. Otherwise just exit. 408 If the "*" label does exist, match RRs at that node against 409 QTYPE. If any match, copy them into the answer section, but 410 set the owner of the RR to be QNAME, and not the node with 411 the "*" label. If the data at the node with the "*" label is 412 a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR 413 into the answer section of the response changing the owner 414 name to the QNAME, change QNAME to the canonical name in the 415 CNAME RR, and go back to step 1. Otherwise, Go to step 6. 417 4. Start matching down in the cache. If QNAME is found in the 418 cache, copy all RRs attached to it that match QTYPE into the 419 answer section. If QNAME is not found in the cache but a DNAME 420 record is present at an ancestor of QNAME, copy that DNAME record 421 into the answer section. If there was no delegation from 422 authoritative data, look for the best one from the cache, and put 423 it in the authority section. Go to step 6. 425 5. Use the local resolver or a copy of its algorithm to answer the 426 query. Store the results, including any intermediate CNAMEs and 427 DNAMEs, in the answer section of the response. 429 6. Using local data only, attempt to add other RRs which may be 430 useful to the additional section of the query. Exit. 432 Note that there will be at most one ancestor with a DNAME as 433 described in step 4 unless some zone's data is in violation of the 434 no-descendants limitation in section 3. An implementation might take 435 advantage of this limitation by stopping the search of step 3c or 436 step 4 when a DNAME record is encountered. 438 3.3. Wildcards 440 The use of DNAME in conjunction with wildcards is discouraged 441 [RFC4592]. Thus records of the form "*.example.com DNAME 442 example.net" SHOULD NOT be used. 444 The interaction between the expansion of the wildcard and the 445 redirection of the DNAME is non-deterministic. Because the 446 processing is non-deterministic, DNSSEC validating resolvers may not 447 be able to validate a wildcarded DNAME. 449 A server MAY give a warning that the behavior is unspecified if such 450 a wildcarded DNAME is loaded. The server MAY refuse it, refuse to 451 load the zone or refuse dynamic updates. 453 3.4. Acceptance and Intermediate Storage 455 Recursive caching name servers can encounter data at names below the 456 owner name of a DNAME RR, due to a change at the authoritative server 457 where data from before and after the change resides in the cache. 458 This conflict situation is a transitional phase that ends when the 459 old data times out. The caching name server can opt to store both 460 old and new data and treat each as if the other did not exist, or 461 drop the old data, or drop the longer domain name. In any approach, 462 consistency returns after the older data TTL times out. 464 Recursive caching name servers MUST perform CNAME synthesis on behalf 465 of clients. 467 If a recursive caching name server encounters a DNSSEC validated 468 DNAME RR which contradicts information already in the cache 469 (excluding CNAME records), it SHOULD cache the DNAME RR, but it MAY 470 cache the CNAME record received along with it, subject to the rules 471 for CNAME. If the DNAME RR cannot be validated via DNSSEC (i.e. not 472 BOGUS, but not able to validate), the recursive caching server SHOULD 473 NOT cache the DNAME RR but MAY cache the CNAME record received along 474 with it, subject to the rules of CNAME. 476 3.4.1. Resolver Algorithm 478 A resolver algorithm likewise changes to handle DNAME processing. 479 The complete algorithm becomes: 481 1. See if the answer is in local information or can be synthesized 482 from a cached DNAME, and if so return it to the client. 484 2. Find the best servers to ask. 486 3. Send queries until one returns a response. 488 4. Analyze the response, either: 490 A. If the response answers the question or contains a name 491 error, cache the data as well as returning it back to the 492 client. 494 B. If the response contains a better delegation to other 495 servers, cache the delegation information, and go to step 2. 497 C. If the response shows a CNAME and that is not the answer 498 itself, cache the CNAME, change the SNAME to the canonical 499 name in the CNAME RR and go to step 1. 501 D. If the response shows a DNAME and that is not the answer 502 itself, cache the DNAME (upon successful DNSSEC validation if 503 the client is a validating resolver). If substitution of the 504 DNAME's target name for its owner name in the SNAME would 505 overflow the legal size for a domain name, return an 506 implementation-dependent error to the application; otherwise 507 perform the substitution and go to step 1. 509 E. If the response shows a server failure or other bizarre 510 contents, delete the server from the SLIST and go back to 511 step 3. 513 4. DNAME Discussions in Other Documents 515 In [RFC2181], in Section 10.3., the discussion on MX and NS records 516 touches on redirection by CNAMEs, but this also holds for DNAMEs. 518 Excerpt from 10.3. MX and NS records (in RFC 2181). 520 The domain name used as the value of a NS resource record, 521 or part of the value of a MX resource record must not be 522 an alias. Not only is the specification clear on this 523 point, but using an alias in either of these positions 524 neither works as well as might be hoped, nor well fulfills 525 the ambition that may have led to this approach. This 526 domain name must have as its value one or more address 527 records. Currently those will be A records, however in 528 the future other record types giving addressing 529 information may be acceptable. It can also have other 530 RRs, but never a CNAME RR. 532 The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. 533 The opening premise of this section is demonstrably wrong, and so the 534 conclusion based on that premise is wrong. In particular, [RFC3363] 535 deprecates the use of DNAME in the IPv6 reverse tree, which is then 536 carried forward as a recommendation in [RFC4294]. Based on the 537 experience gained in the meantime, [RFC3363] is revised, dropping all 538 constraints on having DNAME RRs in these zones. This would greatly 539 improve the manageability of the IPv6 reverse tree. These changes 540 are made explicit below. 542 In [RFC3363], the paragraph 544 "The issues for DNAME in the reverse mapping tree appears to be 545 closely tied to the need to use fragmented A6 in the main tree: if 546 one is necessary, so is the other, and if one isn't necessary, the 547 other isn't either. Therefore, in moving RFC 2874 to experimental, 548 the intent of this document is that use of DNAME RRs in the reverse 549 tree be deprecated." 551 is updated by this document and the use of DNAME RRs in the reverse 552 tree is no longer deprecated. 554 In [RFC4294], the reference to DNAME was left in as an editorial 555 oversight. The paragraph 557 "Those nodes are NOT RECOMMENDED to support the experimental A6 and 558 DNAME Resource Records [RFC3363]." 560 is to be replaced by 562 "Those nodes are NOT RECOMMENDED to support the experimental 563 A6 Resource Record [RFC3363]." 565 5. Other Issues with DNAME 567 There are several issues to be aware of about the use of DNAME. 569 5.1. Canonical hostnames cannot be below DNAME owners 571 The names listed as target names of MX, NS, PTR and SRV [RFC2782] 572 records must be canonical hostnames. This means no CNAME or DNAME 573 redirection may be present during DNS lookup of the address records 574 for the host. This is discussed in RFC 2181 [RFC2181], section 10.3, 575 and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782] 576 page 4. 578 The upshot of this is that although the lookup of a PTR record can 579 involve DNAMEs, the name listed in the PTR record can not fall under 580 a DNAME. The same holds for NS, SRV and MX records. For example, 581 when punycode [RFC3492] alternates for a zone use DNAME then the NS, 582 MX, SRV and PTR records that point to that zone must use names that 583 are not aliases in their RDATA. What must be done then is to have 584 the domain names with DNAME substitution already applied to it as the 585 MX, NS, PTR, SRV data. These are valid canonical hostnames. 587 5.2. Dynamic Update and DNAME 589 DNAME records can be added, changed and removed in a zone using 590 dynamic update transactions. Adding a DNAME RR to a zone occludes 591 any domain names that may exist under the added DNAME. 593 If a dynamic update message attempts to add a DNAME with a given 594 owner name but a CNAME is associated with that name, then the server 595 MUST ignore the DNAME. If a DNAME is already associated with that 596 name, then it is replaced with the new DNAME. Otherwise, add the 597 DNAME. If a CNAME is added with a given owner name but a DNAME is 598 associated with that name, then the CNAME MUST be ignored. This is 599 similar behavior for dynamic updates to an owner name of a CNAME RR 600 [RFC2136]. 602 5.3. DNSSEC and DNAME 604 The following subsections specify the behavior of implementations 605 that understand both DNSSEC and DNAME (synthesis). 607 5.3.1. Signed DNAME, Unsigned Synthesized CNAME 609 In any response, a signed DNAME RR indicates a non-terminal 610 redirection of the query. There might or might not be a server 611 synthesized CNAME in the answer section; if there is, the CNAME will 612 never be signed. For a DNSSEC validator, verification of the DNAME 613 RR and then checking that the CNAME was properly synthesized is 614 sufficient proof. 616 5.3.2. DNAME Bit in NSEC Type Map 618 In any negative response, the NSEC or NSEC3 [RFC5155] record type bit 619 map SHOULD be checked to see that there was no DNAME that could have 620 been applied. If the DNAME bit in the type bit map is set and the 621 query name is a sub-domain of the closest encloser that is asserted, 622 then DNAME substitution should have been done, but the substitution 623 has not been done as specified. 625 5.3.3. DNAME Chains as Strong as the Weakest Link 627 A response can contain a chain of DNAME and CNAME redirections. That 628 chain can end in a positive answer or a negative (no name error or no 629 data error) reply. Each step in that chain results in resource 630 records added to the answer or authority section of the response. 631 Only if all steps are secure can the AD bit be set for the response. 632 If one of the steps is bogus, the result is bogus. 634 5.3.4. Validators Must Understand DNAME 636 Below are examples of why DNSSEC validators MUST understand DNAME. 637 In the examples below, SOA records, wildcard denial NSECs and other 638 material not under discussion has been omitted or shortened. 640 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error 642 ;; Header: QR AA RCODE=3(NXDOMAIN) 643 ;; OPT PSEUDOSECTION: 644 ; EDNS: version: 0, flags: do; udp: 4096 646 ;; Question 647 foo.bar.example.com. IN A 648 ;; Authority 649 bar.example.com. NSEC dub.example.com. A DNAME 650 bar.example.com. RRSIG NSEC [valid signature] 652 If this is the received response, then only by understanding that the 653 DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to 654 have been redirected by the DNAME, the validator can see that it is a 655 BOGUS reply from an attacker that collated existing records from the 656 DNS to create a confusing reply. 658 If the DNAME bit had not been set in the NSEC record above then the 659 answer would have validated as a correct name error response. 661 5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap 663 ;; Header: QR AA RCODE=3(NXDOMAIN) 664 ;; OPT PSEUDOSECTION: 665 ; EDNS: version: 0, flags: do; udp: 4096 667 ;; Question 668 cee.example.com. IN A 669 ;; Authority 670 bar.example.com. NSEC dub.example.com. A DNAME 671 bar.example.com. RRSIG NSEC [valid signature] 673 This response has the same NSEC records as the example above, but 674 with this query name (cee.example.com), the answer is validated, 675 because 'cee' does not get redirected by the DNAME at 'bar'. 677 5.3.4.3. Response With Synthesized CNAME 679 ;; Header: QR AA RCODE=0(NOERROR) 680 ;; OPT PSEUDOSECTION: 681 ; EDNS: version: 0, flags: do; udp: 4096 683 ;; Question 684 foo.bar.example.com. IN A 685 ;; Answer 686 bar.example.com. DNAME bar.example.net. 687 bar.example.com. RRSIG DNAME [valid signature] 688 foo.bar.example.com. CNAME foo.bar.example.net. 690 The response shown above has the synthesized CNAME included. 691 However, the CNAME has no signature, since the server does not sign 692 online. So this response cannot be trusted. It could be altered by 693 an attacker to be foo.bar.example.com CNAME bla.bla.example. The 694 DNAME record does have its signature included, since it does not 695 change. The validator must verify the DNAME signature and then 696 recursively resolve further to query for the foo.bar.example.net A 697 record. 699 6. Examples of DNAME Use in a Zone 701 Below are some examples of the use of DNAME in a zone. These 702 examples are by no means exhaustive. 704 6.1. Organizational Renaming 706 If an organization with domain name FROBOZZ.EXAMPLE.NET became part 707 of an organization with domain name ACME.EXAMPLE.COM, it might ease 708 transition by placing information such as this in its old zone. 710 frobozz.example.net. DNAME frobozz-division.acme.example.com. 711 MX 10 mailhub.acme.example.com. 713 The response to an extended recursive query for 714 www.frobozz.example.net would contain, in the answer section, the 715 DNAME record shown above and the relevant RRs for www.frobozz- 716 division.acme.example.com. 718 If an organization wants to have aliases for names, for a different 719 spelling or language, the same example applies. Note that the MX RR 720 at the zone apex is not redirected and has to be repeated in the 721 target zone. Also note that the services at mailhub or www.frobozz- 722 division.acme.example.com. have to recognize and handle the aliases. 724 6.2. Classless Delegation of Shorter Prefixes 726 The classless scheme for in-addr.arpa delegation [RFC2317] can be 727 extended to prefixes shorter than 24 bits by use of the DNAME record. 728 For example, the prefix 192.0.8.0/22 can be delegated by the 729 following records. 731 $ORIGIN 0.192.in-addr.arpa. 732 8/22 NS ns.slash-22-holder.example.com. 733 8 DNAME 8.8/22 734 9 DNAME 9.8/22 735 10 DNAME 10.8/22 736 11 DNAME 11.8/22 738 A typical entry in the resulting reverse zone for some host with 739 address 192.0.9.33 might be 741 $ORIGIN 8/22.0.192.in-addr.arpa. 742 33.9 PTR somehost.slash-22-holder.example.com. 744 The same advisory remarks concerning the choice of the "/" character 745 apply here as in [RFC2317] . 747 6.3. Network Renumbering Support 749 If IPv4 network renumbering were common, maintenance of address space 750 delegation could be simplified by using DNAME records instead of NS 751 records to delegate. 753 $ORIGIN new-style.in-addr.arpa. 754 189.190 DNAME in-addr.example.net. 756 $ORIGIN in-addr.example.net. 757 188 DNAME in-addr.customer.example.com. 759 $ORIGIN in-addr.customer.example. 760 1 PTR www.customer.example.com 761 2 PTR mailhub.customer.example.com. 762 ; etc ... 764 This would allow the address space 190.189.0.0/16 assigned to the ISP 765 "example.net" to be changed without the necessity of altering the 766 zone data describing the use of that space by the ISP and its 767 customers. 769 Renumbering IPv4 networks is currently so arduous a task that 770 updating the DNS is only a small part of the labor, so this scheme 771 may have a low value. But it is hoped that in IPv6 the renumbering 772 task will be quite different and the DNAME mechanism may play a 773 useful part. 775 7. IANA Considerations 777 The DNAME Resource Record type code 39 (decimal) originally has been 778 registered by [RFC2672] in the DNS Resource Record (RR) Types 779 registry table at http://www.iana.org/assignments/dns-parameters. 780 IANA should update the DNS resource record registry to point to this 781 document for RR type 39. 783 8. Security Considerations 785 DNAME redirects queries elsewhere, which may impact security based on 786 policy and the security status of the zone with the DNAME and the 787 redirection zone's security status. For validating resolvers, the 788 lowest security status of the links in the chain of CNAME and DNAME 789 redirections is applied to the result. 791 If a validating resolver accepts wildcarded DNAMEs, this creates 792 security issues. Since the processing of a wildcarded DNAME is non- 793 deterministic and the CNAME that was substituted by the server has no 794 signature, the resolver may choose a different result than what the 795 server meant, and consequently end up at the wrong destination. Use 796 of wildcarded DNAMEs is discouraged in any case [RFC4592]. 798 A validating resolver MUST understand DNAME, according to [RFC4034]. 799 The examples in Section 5.3.4 illustrate this need. 801 9. Acknowledgments 803 The authors of this draft would like to acknowledge Matt Larson for 804 beginning this effort to address the issues related to the DNAME RR 805 type. The authors would also like to acknowledge Paul Vixie, Ed 806 Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred 807 Hoenes and Kevin Darcy for their review and comments on this 808 document. 810 10. References 812 10.1. Normative References 814 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 815 STD 13, RFC 1034, November 1987. 817 [RFC1035] Mockapetris, P., "Domain names - implementation and 818 specification", STD 13, RFC 1035, November 1987. 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, March 1997. 823 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 824 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 825 RFC 2136, April 1997. 827 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 828 Specification", RFC 2181, July 1997. 830 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 831 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 833 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 834 specifying the location of services (DNS SRV)", RFC 2782, 835 February 2000. 837 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 838 (RR) Types", RFC 3597, September 2003. 840 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 841 Rose, "DNS Security Introduction and Requirements", 842 RFC 4033, March 2005. 844 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 845 Rose, "Resource Records for the DNS Security Extensions", 846 RFC 4034, March 2005. 848 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 850 Rose, "Protocol Modifications for the DNS Security 851 Extensions", RFC 4035, March 2005. 853 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 854 System", RFC 4592, July 2006. 856 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 857 Security (DNSSEC) Hashed Authenticated Denial of 858 Existence", RFC 5155, March 2008. 860 10.2. Informative References 862 [RFC1912] Barr, D., "Common DNS Operational and Configuration 863 Errors", RFC 1912, February 1996. 865 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 866 RFC 2672, August 1999. 868 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 869 Hain, "Representing Internet Protocol version 6 (IPv6) 870 Addresses in the Domain Name System (DNS)", RFC 3363, 871 August 2002. 873 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 874 for Internationalized Domain Names in Applications 875 (IDNA)", RFC 3492, March 2003. 877 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 878 April 2006. 880 Appendix A. Changes from RFC 2672 882 A.1. Changes to Server Behavior 884 Major changes to server behavior from the original DNAME 885 specification are summarized below: 887 o The rules for DNAME substitution have been clarified in Section 2. 889 o The EDNS option to signal DNAME understanding and compression has 890 never been specified, and this document clarifies that there is no 891 signaling method (Section 2.5). 893 o The TTL for synthesized CNAME RR's is now set to the TTL of the 894 DNAME, not zero (Section 3.1). 896 o Caching recursive servers MUST perform CNAME synthesis on behalf 897 of clients (Section 3.4). 899 o The revised server algorithm is detailed in Section 3.2. 901 o Rules for dynamic update messages adding a DNAME or CNAME RR to a 902 zone where a CNAME or DNAME already exists is detailed in Section 903 5.2 905 A.2. Changes to Client Behavior 907 Major changes to client behavior from the original DNAME 908 specification are summarized below: 910 o Clients MUST be able to accept synthesized CNAME RR's with a TTL 911 of either zero or the TTL of the DNAME RR that accompanies the 912 CNAME RR. 914 o DNSSEC aware clients SHOULD cache DNAME RR's and MAY cache 915 synthesized CNAME RR's it receives in the same response. DNSSEC 916 aware clients SHOULD also check the NSEC/NSEC3 type bitmap to 917 verify that DNAME redirection is to be done. DNSSEC validators 918 MUST understand DNAME (Section 5.3). 920 o The revised client algorithm is detailed in Section 3.4.1. 922 Authors' Addresses 924 Scott Rose 925 NIST 926 100 Bureau Dr. 927 Gaithersburg, MD 20899 928 USA 930 Phone: +1-301-975-8439 931 Fax: +1-301-975-6238 932 EMail: scottr.nist@gmail.com 934 Wouter Wijngaards 935 NLnet Labs 936 Science Park 140 937 Amsterdam 1098 XG 938 The Netherlands 940 Phone: +31-20-888-4551 941 EMail: wouter@nlnetlabs.nl