idnits 2.17.1 draft-ietf-dnsext-rfc2672bis-dname-22.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 : ---------------------------------------------------------------------------- -- 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (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 (May 2, 2011) is 4742 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 219 -- 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 (~~), 2 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 NLnet Labs 6 (if approved) May 2, 2011 7 Intended status: Standards Track 8 Expires: November 3, 2011 10 Update to DNAME Redirection in the DNS 11 draft-ietf-dnsext-rfc2672bis-dname-22 13 Abstract 15 The DNAME record provides redirection for a sub-tree of the domain 16 name tree in the DNS system. That is, all names that end with a 17 particular suffix are redirected to another part of the DNS. This is 18 a revision of the original specification in RFC 2672, also aligning 19 RFC 3363 and RFC 4294 with this revision. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 3, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 76 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 78 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 7 79 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 80 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 82 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 84 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9 85 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11 86 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11 88 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11 90 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 13 91 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 13 92 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13 93 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13 94 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13 95 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14 96 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14 97 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14 98 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 14 99 5.3.4.2. Valid Name Error Response Involving DNAME in 100 Bitmap . . . . . . . . . . . . . . . . . . . . . . 15 101 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 15 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 107 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 109 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 110 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 111 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 113 1. Introduction 115 DNAME is a DNS Resource Record type originally defined in RFC 2672 116 [RFC2672]. DNAME provides redirection from a part of the DNS name 117 tree to another part of the DNS name tree. 119 The DNAME RR and the CNAME RR [RFC1034] cause a lookup to 120 (potentially) return data corresponding to a domain name different 121 from the queried domain name. The difference between the two 122 resource records is that the CNAME RR directs the lookup of data at 123 its owner to another single name, a DNAME RR directs lookups for data 124 at descendants of its owner's name to corresponding names under a 125 different (single) node of the tree. 127 Take for example, looking through a zone (see RFC 1034 [RFC1034], 128 section 4.3.2, step 3) for the domain name "foo.example.com" and a 129 DNAME resource record is found at "example.com" indicating that all 130 queries under "example.com" be directed to "example.net". The lookup 131 process will return to step 1 with the new query name of 132 "foo.example.net". Had the query name been "www.foo.example.com" the 133 new query name would be "www.foo.example.net". 135 This document is a revision of the original specification of DNAME in 136 RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of 137 maintaining address-to-name mappings in a context of network 138 renumbering. With a careful set-up, a renumbering event in the 139 network causes no change to the authoritative server that has the 140 address-to-name mappings. Examples in practice are classless reverse 141 address space delegations. 143 Another usage of DNAME lies in aliasing of name spaces. For example, 144 a zone administrator may want sub-trees of the DNS to contain the 145 same information. Examples include punycode alternates for domain 146 spaces. 148 This revision to DNAME does not change the wire format or the 149 handling of DNAME Resource Records. Discussion is added on problems 150 that may be encountered when using DNAME. 152 2. The DNAME Resource Record 154 2.1. Format 156 The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is 157 not class-sensitive. 159 Its RDATA is comprised of a single field, , which contains a 160 fully qualified domain name that must be sent in uncompressed form 161 [RFC1035], [RFC3597]. The field MUST be present. The 162 presentation format of is that of a domain name [RFC1035]. 164 DNAME 166 The effect of the DNAME RR is the substitution of the record's 167 for its owner name, as a suffix of a domain name. This 168 substitution is to be applied for all names below the owner name of 169 the DNAME RR. This substitution has to be applied for every DNAME RR 170 found in the resolution process, which allows fairly lengthy valid 171 chains of DNAME RRs. 173 Details of the substitution process, methods to avoid conflicting 174 resource records, and rules for specific corner cases are given in 175 the following subsections. 177 2.2. The DNAME Substitution 179 When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third 180 step, "start matching down, label by label, in the zone" and a node 181 is found to own a DNAME resource record a DNAME substitution occurs. 182 The name being sought may be the original query name or a name that 183 is the result of a CNAME resource record being followed or a 184 previously encountered DNAME. As in the case when finding a CNAME 185 resource record or NS resource record set, the processing of a DNAME 186 will happen prior to finding the desired domain name. 188 A DNAME substitution is performed by replacing the suffix labels of 189 the name being sought matching the owner name of the DNAME resource 190 record with the string of labels in the RDATA field. The matching 191 labels end with the root label in all cases. Only whole labels are 192 replaced. See the table of examples for common cases and corner 193 cases. 195 In the table below, the QNAME refers to the query name. The owner is 196 the DNAME owner domain name, and the target refers to the target of 197 the DNAME record. The result is the resulting name after performing 198 the DNAME substitution on the query name. "no match" means that the 199 query did not match the DNAME and thus no substitution is performed 200 and a possible error message is returned (if no other result is 201 possible). Thus every line contains one example substitution. In 202 the examples below, 'cyc' and 'shortloop' contain loops. 204 QNAME owner DNAME target result 205 ---------------- -------------- -------------- ----------------- 206 com. example.com. example.net. 207 example.com. example.com. example.net. [0] 208 a.example.com. example.com. example.net. a.example.net. 209 a.b.example.com. example.com. example.net. a.b.example.net. 210 ab.example.com. b.example.com. example.net. 211 foo.example.com. example.com. example.net. foo.example.net. 212 a.x.example.com. x.example.com. example.net. a.example.net. 213 a.example.com. example.com. y.example.net. a.y.example.net. 214 cyc.example.com. example.com. example.com. cyc.example.com. 215 cyc.example.com. example.com. c.example.com. cyc.c.example.com. 216 shortloop.x.x. x. . shortloop.x. 217 shortloop.x. x. . shortloop. 219 [0] The result depends on the QTYPE. If the QTYPE = DNAME, then 220 the result is "example.com." else "" 222 Table 1. DNAME Substitution Examples. 224 It is possible for DNAMEs to form loops, just as CNAMEs can form 225 loops. DNAMEs and CNAMEs can chain together to form loops. A single 226 corner case DNAME can form a loop. Resolvers and servers should be 227 cautious in devoting resources to a query, but be aware that fairly 228 long chains of DNAMEs may be valid. Zone content administrators 229 should take care to insure that there are no loops that could occur 230 when using DNAME or DNAME/CNAME redirection. 232 The domain name can get too long during substitution. For example, 233 suppose the target name of the DNAME RR is 250 octets in length 234 (multiple labels), if an incoming QNAME that has a first label over 5 235 octets in length, the result would be a name over 255 octets. If 236 this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The 237 DNAME record and its signature (if the zone is signed) are included 238 in the answer as proof for the YXDOMAIN (value 6) RCODE. 240 2.3. DNAME Owner Name Matching the QNAME 242 Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its 243 owner name; the owner name of a DNAME is not redirected itself. The 244 domain name that owns a DNAME record is allowed to have other 245 resource record types at that domain name, except DNAMEs, CNAMEs or 246 other types that have restrictions on what they can co-exist with. 247 When there is a match of the QTYPE to a type (or types) also owned by 248 the owner name the response is sourced from the owner name. E.g., a 249 QTYPE of ANY would return the (available) types at the owner name, 250 not the target name. 252 DNAME RRs MUST NOT appear at the same owner name as an NS RR unless 253 the owner name is the zone apex as this would constitute data below a 254 zone cut. 256 If a DNAME record is present at the zone apex, there is still a need 257 to have the customary SOA and NS resource records there as well. 258 Such a DNAME cannot be used to mirror a zone completely, as it does 259 not mirror the zone apex. 261 These rules also allow DNAME records to be queried through RFC 1034 262 [RFC1034] compliant, DNAME-unaware caches. 264 2.4. Names Next to and Below a DNAME Record 266 Resource records MUST NOT exist at any sub-domain of the owner of a 267 DNAME RR. To get the contents for names subordinate to that owner 268 name, the DNAME redirection must be invoked and the resulting target 269 queried. A server MAY refuse to load a zone that has data at a sub- 270 domain of a domain name owning a DNAME RR. If the server does load 271 the zone, those names below the DNAME RR will be occluded as 272 described in RFC 2136 [RFC2136], section 7.18. Also a server SHOULD 273 refuse to load a zone subordinate to the owner of a DNAME record in 274 the ancestor zone. See Section 5.2 for further discussion related to 275 dynamic update. 277 DNAME is a singleton type, meaning only one DNAME is allowed per 278 name. The owner name of a DNAME can only have one DNAME RR, and no 279 CNAME RRs can exist at that name. These rules make sure that for a 280 single domain name only one redirection exists, and thus no confusion 281 which one to follow. A server SHOULD refuse to load a zone that 282 violates these rules. 284 2.5. Compression of the DNAME record. 286 The DNAME owner name can be compressed like any other owner name. 287 The DNAME RDATA target name MUST NOT be sent out in compressed form, 288 so that a DNAME RR can be treated as an unknown type [RFC3597]. 290 Although the previous DNAME specification [RFC2672] (that is 291 obsoleted by this specification) talked about signaling to allow 292 compression of the target name, such signaling has never been 293 specified and this document also does not specify this signaling 294 behavior. 296 RFC 2672 (obsoleted by this document) stated that the EDNS version 297 had a meaning for understanding of DNAME and DNAME target name 298 compression. This document revises RFC 2672, in that there is no 299 EDNS version signaling for DNAME. 301 3. Processing 303 3.1. CNAME synthesis 305 When preparing a response, a server performing a DNAME substitution 306 will in all cases include the relevant DNAME RR in the answer 307 section. Relevant includes the following cases: 309 1. The DNAME is being employed as a substitution instruction. 311 2. The DNAME itself matches the QTYPE and the owner name matches 312 QNAME. 314 When the owner name name matches the QNAME and the QTYPE matches 315 another type owned there, the DNAME is not included in the answer. 317 A CNAME RR with TTL equal to the corresponding DNAME RR is 318 synthesized and included in the answer section when the DNAME is 319 employed as a substitution instruction. The owner name of the CNAME 320 is the QNAME of the query. The DNSSEC specification [RFC4033], 321 [RFC4034], [RFC4035] says that the synthesized CNAME does not have to 322 be signed. The DNAME has an RRSIG and a validating resolver can 323 check the CNAME against the DNAME record and validate the signature 324 over the DNAME RR. 326 Servers MUST be able to answer a query for a synthesized CNAME. Like 327 other query types this invokes the DNAME, and synthesizes the CNAME 328 into the answer. If the server in question is a cache, the 329 synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the 330 cached DNAME. 332 Resolvers MUST be able to handle a synthesized CNAME TTL of zero or 333 equal to the TTL of the corresponding DNAME record (as some older 334 authoritative server implementations set the TTL of synthesized 335 CNAMEs to zero). A TTL of zero means that the CNAME can be discarded 336 immediately after processing the answer. 338 3.2. Server algorithm 340 Below is the server algorithm, which appeared in RFC 2672 Section 341 4.1. 343 1. Set or clear the value of recursion available in the response 344 depending on whether the name server is willing to provide 345 recursive service. If recursive service is available and 346 requested via the RD bit in the query, go to step 5, otherwise 347 step 2. 349 2. Search the available zones for the zone which is the nearest 350 ancestor to QNAME. If such a zone is found, go to step 3, 351 otherwise step 4. 353 3. Start matching down, label by label, in the zone. The matching 354 process can terminate several ways: 356 A. If the whole of QNAME is matched, we have found the node. 358 If the data at the node is a CNAME, and QTYPE does not match 359 CNAME, copy the CNAME RR into the answer section of the 360 response, change QNAME to the canonical name in the CNAME RR, 361 and go back to step 1. 363 Otherwise, copy all RRs which match QTYPE into the answer 364 section and go to step 6. 366 B. If a match would take us out of the authoritative data, we 367 have a referral. This happens when we encounter a node with 368 NS RRs marking cuts along the bottom of a zone. 370 Copy the NS RRs for the sub-zone into the authority section 371 of the reply. Put whatever addresses are available into the 372 additional section, using glue RRs if the addresses are not 373 available from authoritative data or the cache. Go to step 374 4. 376 C. If at some label, a match is impossible (i.e., the 377 corresponding label does not exist), look to see whether the 378 last label matched has a DNAME record. 380 If a DNAME record exists at that point, copy that record into 381 the answer section. If substitution of its for its 382 in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise 384 perform the substitution and continue. The server MUST 385 synthesize a CNAME record as described above and include it 386 in the answer section. Go back to step 1. 388 If there was no DNAME record, look to see if the "*" label 389 exists. 391 If the "*" label does not exist, check whether the name we 392 are looking for is the original QNAME in the query or a name 393 we have followed due to a CNAME or DNAME. If the name is 394 original, set an authoritative name error in the response and 395 exit. Otherwise just exit. 397 If the "*" label does exist, match RRs at that node against 398 QTYPE. If any match, copy them into the answer section, but 399 set the owner of the RR to be QNAME, and not the node with 400 the "*" label. If the data at the node with the "*" label is 401 a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR 402 into the answer section of the response changing the owner 403 name to the QNAME, change QNAME to the canonical name in the 404 CNAME RR, and go back to step 1. Otherwise, Go to step 6. 406 4. Start matching down in the cache. If QNAME is found in the 407 cache, copy all RRs attached to it that match QTYPE into the 408 answer section. If QNAME is not found in the cache but a DNAME 409 record is present at an ancestor of QNAME, copy that DNAME record 410 into the answer section. If there was no delegation from 411 authoritative data, look for the best one from the cache, and put 412 it in the authority section. Go to step 6. 414 5. Use the local resolver or a copy of its algorithm to answer the 415 query. Store the results, including any intermediate CNAMEs and 416 DNAMEs, in the answer section of the response. 418 6. Using local data only, attempt to add other RRs which may be 419 useful to the additional section of the query. Exit. 421 Note that there will be at most one ancestor with a DNAME as 422 described in step 4 unless some zone's data is in violation of the 423 no-descendants limitation in section 3. An implementation might take 424 advantage of this limitation by stopping the search of step 3c or 425 step 4 when a DNAME record is encountered. 427 3.3. Wildcards 429 The use of DNAME in conjunction with wildcards is discouraged 430 [RFC4592]. Thus records of the form "*.example.com DNAME 431 example.net" SHOULD NOT be used. 433 The interaction between the expansion of the wildcard and the 434 redirection of the DNAME is non-deterministic. Because the 435 processing is non-deterministic, DNSSEC validating resolvers may not 436 be able to validate a wildcarded DNAME. 438 A server MAY give a warning that the behavior is unspecified if such 439 a wildcarded DNAME is loaded. The server MAY refuse it, refuse to 440 load the zone or refuse dynamic updates. 442 3.4. Acceptance and Intermediate Storage 444 Recursive caching name servers can encounter data at names below the 445 owner name of a DNAME RR, due to a change at the authoritative server 446 where data from before and after the change resides in the cache. 447 This conflict situation is a transitional phase that ends when the 448 old data times out. The caching name server can opt to store both 449 old and new data and treat each as if the other did not exist, or 450 drop the old data, or drop the longer domain name. In any approach, 451 consistency returns after the older data TTL times out. 453 Recursive caching name servers MUST perform CNAME synthesis on behalf 454 of clients. 456 If a recursive caching name server encounters a DNAME RR which 457 contradicts information already in the cache (excluding CNAME 458 records), it SHOULD NOT cache the DNAME RR, but it MAY cache the 459 CNAME record received along with it, subject to the rules for CNAME. 461 4. DNAME Discussions in Other Documents 463 In [RFC2181], in Section 10.3., the discussion on MX and NS records 464 touches on redirection by CNAMEs, but this also holds for DNAMEs. 466 Excerpt from 10.3. MX and NS records (in RFC 2181). 468 The domain name used as the value of a NS resource record, 469 or part of the value of a MX resource record must not be 470 an alias. Not only is the specification clear on this 471 point, but using an alias in either of these positions 472 neither works as well as might be hoped, nor well fulfills 473 the ambition that may have led to this approach. This 474 domain name must have as its value one or more address 475 records. Currently those will be A records, however in 476 the future other record types giving addressing 477 information may be acceptable. It can also have other 478 RRs, but never a CNAME RR. 480 The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. 481 The opening premise of this section is demonstrably wrong, and so the 482 conclusion based on that premise is wrong. In particular, [RFC3363] 483 deprecates the use of DNAME in the IPv6 reverse tree, which is then 484 carried forward as a recommendation in [RFC4294]. Based on the 485 experience gained in the meantime, [RFC3363] should be revised, 486 dropping all constraints on having DNAME RRs in these zones. This 487 would greatly improve the manageability of the IPv6 reverse tree. 488 These changes are made explicit below. 490 In [RFC3363], the paragraph 492 "The issues for DNAME in the reverse mapping tree appears to be 493 closely tied to the need to use fragmented A6 in the main tree: if 494 one is necessary, so is the other, and if one isn't necessary, the 495 other isn't either. Therefore, in moving RFC 2874 to experimental, 496 the intent of this document is that use of DNAME RRs in the reverse 497 tree be deprecated." 499 is to be replaced with the word "DELETED". 501 In [RFC4294], the reference to DNAME was left in as an editorial 502 oversight. The paragraph 504 "Those nodes are NOT RECOMMENDED to support the experimental A6 and 505 DNAME Resource Records [RFC3363]." 507 is to be replaced by 509 "Those nodes are NOT RECOMMENDED to support the experimental 510 A6 Resource Record [RFC3363]." 512 5. Other Issues with DNAME 514 There are several issues to be aware of about the use of DNAME. 516 5.1. Canonical hostnames cannot be below DNAME owners 518 The names listed as target names of MX, NS, PTR and SRV [RFC2782] 519 records must be canonical hostnames. This means no CNAME or DNAME 520 redirection may be present during DNS lookup of the address records 521 for the host. This is discussed in RFC 2181 [RFC2181], section 10.3, 522 and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782] 523 page 4. 525 The upshot of this is that although the lookup of a PTR record can 526 involve DNAMEs, the name listed in the PTR record can not fall under 527 a DNAME. The same holds for NS, SRV and MX records. For example, 528 when punycode alternates for a zone use DNAME then the NS, MX, SRV 529 and PTR records that point to that zone must use names without 530 punycode in their RDATA. What must be done then is to have the 531 domain names with DNAME substitution already applied to it as the MX, 532 NS, PTR, SRV data. These are valid canonical hostnames. 534 5.2. Dynamic Update and DNAME 536 DNAME records can be added, changed and removed in a zone using 537 dynamic update transactions. Adding a DNAME RR to a zone occludes 538 any domain names that may exist under the added DNAME. 540 If a dynamic update message attempts to add a DNAME with a given 541 owner name but a CNAME is associated with that name, then the server 542 MUST ignore the DNAME. If a DNAME is already associated with that 543 name, then it is replaced with the new DNAME. Otherwise, add the 544 DNAME. If a CNAME is added with a given owner name but a DNAME is 545 associated with that name, then the CNAME MUST be ignored. This is 546 similar behavior for dynamic updates to an owner name of a CNAME RR 547 [RFC2136]. 549 5.3. DNSSEC and DNAME 551 The following subsections specify the behavior of implementations 552 that understand both DNSSEC and DNAME (synthesis). 554 5.3.1. Signed DNAME, Unsigned Synthesized CNAME 556 In any response, a signed DNAME RR indicates a non-terminal 557 redirection of the query. There might or might not be a server 558 synthesized CNAME in the answer section; if there is, the CNAME will 559 never be signed. For a DNSSEC validator, verification of the DNAME 560 RR and then checking that the CNAME was properly synthesized is 561 sufficient proof. 563 5.3.2. DNAME Bit in NSEC Type Map 565 In any negative response, the NSEC or NSEC3 [RFC5155] record type bit 566 map SHOULD be checked to see that there was no DNAME that could have 567 been applied. If the DNAME bit in the type bit map is set and the 568 query name is a sub-domain of the closest encloser that is asserted, 569 then DNAME substitution should have been done, but the substitution 570 has not been done as specified. 572 5.3.3. DNAME Chains as Strong as the Weakest Link 574 A response can contain a chain of DNAME and CNAME redirections. That 575 chain can end in a positive answer or a negative (no name error or no 576 data error) reply. Each step in that chain results in resource 577 records added to the answer or authority section of the response. 578 Only if all steps are secure can the AD bit be set for the response. 579 If one of the steps is bogus, the result is bogus. 581 5.3.4. Validators Must Understand DNAME 583 Below are examples of why DNSSEC validators MUST understand DNAME. 584 In the examples below, SOA records, wildcard denial NSECs and other 585 material not under discussion has been omitted or shortened. 587 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error 589 ;; Header: QR AA RCODE=3(NXDOMAIN) 590 ;; OPT PSEUDOSECTION: 591 ; EDNS: version: 0, flags: do; udp: 4096 593 ;; Question 594 foo.bar.example.com. IN A 595 ;; Authority 596 bar.example.com. NSEC dub.example.com. A DNAME 597 bar.example.com. RRSIG NSEC [valid signature] 599 If this is the received response, then only by understanding that the 600 DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to 601 have been redirected by the DNAME, the validator can see that it is a 602 BOGUS reply from an attacker that collated existing records from the 603 DNS to create a confusing reply. 605 If the DNAME bit had not been set in the NSEC record above then the 606 answer would have validated as a correct name error response. 608 5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap 610 ;; Header: QR AA RCODE=3(NXDOMAIN) 611 ;; OPT PSEUDOSECTION: 612 ; EDNS: version: 0, flags: do; udp: 4096 614 ;; Question 615 cee.example.com. IN A 616 ;; Authority 617 bar.example.com. NSEC dub.example.com. A DNAME 618 bar.example.com. RRSIG NSEC [valid signature] 620 This response has the same NSEC records as the example above, but 621 with this query name (cee.example.com), the answer is validated, 622 because 'cee' does not get redirected by the DNAME at 'bar'. 624 5.3.4.3. Response With Synthesized CNAME 626 ;; Header: QR AA RCODE=0(NOERROR) 627 ;; OPT PSEUDOSECTION: 628 ; EDNS: version: 0, flags: do; udp: 4096 630 ;; Question 631 foo.bar.example.com. IN A 632 ;; Answer 633 bar.example.com. DNAME bar.example.net. 634 bar.example.com. RRSIG DNAME [valid signature] 635 foo.bar.example.com. CNAME foo.bar.example.net. 637 The response shown above has the synthesized CNAME included. 638 However, the CNAME has no signature, since the server does not sign 639 online. So this response cannot be trusted. It could be altered by 640 an attacker to be foo.bar.example.com CNAME bla.bla.example. The 641 DNAME record does have its signature included, since it does not 642 change. The validator must verify the DNAME signature and then 643 recursively resolve further to query for the foo.bar.example.net A 644 record. 646 6. IANA Considerations 648 The DNAME Resource Record type code 39 (decimal) originally has been 649 registered by [RFC2672]. IANA should update the DNS resource record 650 registry to point to this document for RR type 39. 652 7. Security Considerations 654 DNAME redirects queries elsewhere, which may impact security based on 655 policy and the security status of the zone with the DNAME and the 656 redirection zone's security status. For validating resolvers, the 657 lowest security status of the links in the chain of CNAME and DNAME 658 redirections is applied to the result. 660 If a validating resolver accepts wildcarded DNAMEs, this creates 661 security issues. Since the processing of a wildcarded DNAME is non- 662 deterministic and the CNAME that was substituted by the server has no 663 signature, the resolver may choose a different result than what the 664 server meant, and consequently end up at the wrong destination. Use 665 of wildcarded DNAMEs is discouraged in any case [RFC4592]. 667 A validating resolver MUST understand DNAME, according to [RFC4034]. 668 The examples in Section 5.3.4 illustrate this need. 670 8. Acknowledgments 672 The authors of this draft would like to acknowledge Matt Larson for 673 beginning this effort to address the issues related to the DNAME RR 674 type. The authors would also like to acknowledge Paul Vixie, Ed 675 Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred 676 Hoenes and Kevin Darcy for their review and comments on this 677 document. 679 9. References 681 9.1. Normative References 683 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 684 STD 13, RFC 1034, November 1987. 686 [RFC1035] Mockapetris, P., "Domain names - implementation and 687 specification", STD 13, RFC 1035, November 1987. 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, March 1997. 692 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 693 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 694 RFC 2136, April 1997. 696 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 697 Specification", RFC 2181, July 1997. 699 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 700 specifying the location of services (DNS SRV)", RFC 2782, 701 February 2000. 703 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 704 (RR) Types", RFC 3597, September 2003. 706 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 707 Rose, "DNS Security Introduction and Requirements", 708 RFC 4033, March 2005. 710 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 711 Rose, "Resource Records for the DNS Security Extensions", 712 RFC 4034, March 2005. 714 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 715 Rose, "Protocol Modifications for the DNS Security 716 Extensions", RFC 4035, March 2005. 718 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 719 System", RFC 4592, July 2006. 721 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 722 Security (DNSSEC) Hashed Authenticated Denial of 723 Existence", RFC 5155, March 2008. 725 9.2. Informative References 727 [RFC1912] Barr, D., "Common DNS Operational and Configuration 728 Errors", RFC 1912, February 1996. 730 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 731 RFC 2672, August 1999. 733 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 734 Hain, "Representing Internet Protocol version 6 (IPv6) 735 Addresses in the Domain Name System (DNS)", RFC 3363, 736 August 2002. 738 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 739 April 2006. 741 Authors' Addresses 743 Scott Rose 744 NIST 745 100 Bureau Dr. 746 Gaithersburg, MD 20899 747 USA 749 Phone: +1-301-975-8439 750 Fax: +1-301-975-6238 751 EMail: scottr.nist@gmail.com 753 Wouter Wijngaards 754 NLnet Labs 755 Science Park 140 756 Amsterdam 1098 XG 757 The Netherlands 759 Phone: +31-20-888-4551 760 EMail: wouter@nlnetlabs.nl