idnits 2.17.1 draft-ietf-dnsext-wcard-clarify-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 956. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 567 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 2006) is 6618 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC 2136' is mentioned on line 705, but not defined == Unused Reference: 'RFC2136' is defined on line 889, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft dnsext-wcard March 13, 2006 3 DNSEXT Working Group E. Lewis 4 INTERNET DRAFT NeuStar 5 Expiration Date: September 13, 2006 March 13, 2006 6 Updates RFC 1034, RFC 2672 8 The Role of Wildcards 9 in the Domain Name System 10 draft-ietf-dnsext-wcard-clarify-11.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on September 13, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This is an update to the wildcard definition of RFC 1034. The 46 interaction with wildcards and CNAME is changed, an error 47 condition removed, and the words defining some concepts central 48 to wildcards are changed. The overall goal is not to change 49 wildcards, but to refine the definition of RFC 1034. 51 DNSEXT Working Group Expires September 13, 2006 [Page 1] 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . 3 55 1 1 Motivation 3 56 1 2 The Original Definition 3 57 1 3 Roadmap to This Document 4 58 1 3 1 New Terms 4 59 1.3.2 Changed Text 5 60 1.3.3 Considerations with Special Types 5 61 1.4 Standards Terminology 5 62 2. Wildcard Syntax . . . . . . . . . . . . . . . 6 63 2.1 Identifying a Wildcard 6 64 2.1.1 Wildcard Domain Name and Asterisk Label 6 65 2.1.2 Asterisks and Other Characters 6 66 2.1.3 Non-terminal Wildcard Domain Names 6 67 2.2 Existence Rules 7 68 2.2.1 An Example 7 69 2.2.2 Empty Non-terminals 9 70 2.2.3 Yet Another Definition of Existence 10 71 2.3 When is a Wildcard Domain Name Not Special 10 72 3. Impact of a Wildcard Domain Name On a Response . . . . . 10 73 3.1 Step 2 10 74 3.2 Step 3 11 75 3.3 Part 'c' 11 76 3.3.1 Closest Encloser and the Source of Synthesis 12 77 3.3.2 Closest Encloser and Source of Synthesis Examples 12 78 3.3.3 Type Matching 13 79 4. Considerations with Special Types . . . . . . . . . 13 80 4.1 SOA RRSet at a Wildcard Domain Name 13 81 4.2 NS RRSet at a Wildcard Domain Name 14 82 4.2.1 Discarded Notions 14 83 4.3 CNAME RRSet at a Wildcard Domain Name 15 84 4.4 DNAME RRSet at a Wildcard Domain Name 15 85 4.5 SRV RRSet at a Wildcard Domain Name 16 86 4.6 DS RRSet at a Wildcard Domain Name 17 87 4.7 NSEC RRSet at a Wildcard Domain Name 17 88 4.8 RRSIG at a Wildcard Domain Name 17 89 4.9 Empty Non-terminal Wildcard Domain Name 17 90 5. Security Considerations . . . . . . . . . . . . . 17 91 6. IANA Considerations . . . . . . . . . . . . . 17 92 7. References . . . . . . . . . . . . . 17 93 8. Editor . . . . . . . . . . . . . 18 94 9. Others Contributing to the Document . . . . . . . . 18 95 10. Trailing Boilerplate . . . . . . . . . . . . . 19 97 DNSEXT Working Group Expires September 13, 2006 [Page 2] 98 1. Introduction 100 In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the 101 synthesis of answers from special resource records called 102 wildcards. The definition in RFC 1034 is incomplete and has 103 proven to be confusing. This document describes the wildcard 104 synthesis by adding to the discussion and making limited 105 modifications. Modifications are made to close inconsistencies 106 that have led to interoperability issues. This description 107 does not expand the service intended by the original definition. 109 Staying within the spirit and style of the original documents, 110 this document avoids specifying rules for DNS implementations 111 regarding wildcards. The intention is to only describe what is 112 needed for interoperability, not restrict implementation choices. 113 In addition, consideration is given to minimize any backwards 114 compatibility issues with implementations that comply with RFC 115 1034's definition. 117 This document is focused on the concept of wildcards as defined 118 in RFC 1034. Nothing is implied regarding alternative means of 119 synthesizing resource record sets, nor are alternatives discussed. 121 1.1 Motivation 123 Many DNS implementations diverge, in different ways, from the 124 original definition of wildcards. Although there is clearly a 125 need to clarify the original documents in light of this alone, 126 the impetus for this document lay in the engineering of the DNS 127 security extensions [RFC4033]. With an unclear definition of 128 wildcards the design of authenticated denial became entangled. 130 This document is intended to limit its changes, documenting only 131 those based on implementation experience, and to remain as close 132 to the original document as possible. To reinforce that this 133 document is meant to clarify and adjust and not redefine 134 wildcards, relevant sections of RFC 1034 are repeated verbatim 135 to facilitate comparison of the old and new text. 137 1.2 The Original Definition 139 The definition of the wildcard concept is comprised by the 140 documentation of the algorithm by which a name server prepares 141 a response (in RFC 1034's section 4.3.2) and the way in which 142 a resource record (set) is identified as being a source of 143 synthetic data (section 4.3.3). 145 This is the definition of the term "wildcard" as it appears in 146 RFC 1034, section 4.3.3. 148 DNSEXT Working Group Expires September 13, 2006 [Page 3] 149 # In the previous algorithm, special treatment was given to RRs with 150 # owner names starting with the label "*". Such RRs are called 151 # wildcards. Wildcard RRs can be thought of as instructions for 152 # synthesizing RRs. When the appropriate conditions are met, the name 153 # server creates RRs with an owner name equal to the query name and 154 # contents taken from the wildcard RRs. 156 This passage follows the algorithm in which the term wildcard 157 is first used. In this definition, wildcard refers to resource 158 records. In other usage, wildcard has referred to domain names, 159 and it has been used to describe the operational practice of 160 relying on wildcards to generate answers. It is clear from this 161 that there is a need to define clear and unambiguous terminology 162 in the process of discussing wildcards. 164 The mention of the use of wildcards in the preparation of a 165 response is contained in step 3c of RFC 1034's section 4.3.2 166 entitled "Algorithm." Note that "wildcard" does not appear in 167 the algorithm, instead references are made to the "*" label. 168 The portion of the algorithm relating to wildcards is 169 deconstructed in detail in section 3 of this document, this is 170 the beginning of the relevant portion of the "Algorithm." 172 # c. If at some label, a match is impossible (i.e., the 173 # corresponding label does not exist), look to see if [...] 174 # the "*" label exists. 176 The scope of this document is the RFC 1034 definition of 177 wildcards and the implications of updates to those documents, 178 such as DNSSEC. Alternate schemes for synthesizing answers are 179 not considered. (Note that there is no reference listed. No 180 document is known to describe any alternate schemes, although 181 there has been some mention of them in mailing lists.) 183 1.3 Roadmap to This Document 185 This document accomplishes these three items. 186 o Defines new terms 187 o Makes minor changes to avoid conflicting concepts 188 o Describes the actions of certain resource records as wildcards 190 1.3.1 New Terms 192 To help in discussing what resource records are wildcards, two 193 terms will be defined - "asterisk label" and "wildcard domain 194 name". These are defined in section 2.1.1. 196 To assist in clarifying the role of wildcards in the name server 197 algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest 198 encloser" are defined. These definitions are in section 3.3.2. 199 "Label match" is defined in section 3.2. 201 DNSEXT Working Group Expires September 13, 2006 [Page 4] 202 The new terms are used to make discussions of wildcards clearer. 203 Terminology doesn't directly have an impact on implementations. 205 1.3.2 Changed Text 207 The definition of "existence" is changed superficially. This 208 change will not be apparent to implementations; it is needed to 209 make descriptions more precise. The change appears in section 210 2.2.3. 212 RFC 1034, section 4.3.3., seems to prohibit having two asterisk 213 labels in a wildcard owner name. With this document the 214 restriction is removed entirely. This change and its implications 215 are in section 2.1.3. 217 The actions when a source of synthesis owns a CNAME RR are 218 changed to mirror the actions if an exact match name owns a 219 CNAME RR. This is an addition to the words in RFC 1034, 220 section 4.3.2, step 3, part c. The discussion of this is in 221 section 3.3.3. 223 Only the latter change represents an impact to implementations. 224 The definition of existence is not a protocol impact. The change 225 to the restriction on names is unlikely to have an impact, as 226 RFC 1034 contained no specification on when and how to enforce the 227 restriction. 229 1.3.3 Considerations with Special Types 231 This document describes semantics of wildcard RRSets for 232 "interesting" types as well as empty non-terminal wildcards. 233 Understanding these situations in the context of wildcards has 234 been clouded because these types incur special processing if 235 they are the result of an exact match. This discussion is in 236 section 4. 238 These discussions do not have an implementation impact, they cover 239 existing knowledge of the types, but to a greater level of detail. 241 1.4 Standards Terminology 243 This document does not use terms as defined in "Key words for use 244 in RFCs to Indicate Requirement Levels." [RFC2119] 246 Quotations of RFC 1034 are denoted by a '#' in the leftmost 247 column. References to section "4.3.2" are assumed to refer 248 to RFC 1034's section 4.3.2, simply titled "Algorithm." 250 DNSEXT Working Group Expires September 13, 2006 [Page 5] 251 2. Wildcard Syntax 253 The syntax of a wildcard is the same as any other DNS resource 254 record, across all classes and types. The only significant 255 feature is the owner name. 257 Because wildcards are encoded as resource records with special 258 names, they are included in zone transfers and incremental zone 259 transfers[RFC1995] just as non-wildcard resource records are. 260 This feature has been under appreciated until discussions on 261 alternative approaches to wildcards appeared on mailing lists. 263 2.1 Identifying a Wildcard 265 To provide a more accurate description of wildcards, the 266 definition has to start with a discussion of the domain names 267 that appear as owners. Two new terms are needed, "Asterisk 268 Label" and "Wildcard Domain Name." 270 2.1.1 Wildcard Domain Name and Asterisk Label 272 A "wildcard domain name" is defined by having its initial 273 (i.e., left-most or least significant) label be, in binary format: 275 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) 277 The first octet is the normal label type and length for a 1 octet 278 long label, the second octet is the ASCII representation [RFC20] 279 for the '*' character. 281 A descriptive name of a label equaling that value is an "asterisk 282 label." 284 RFC 1034's definition of wildcard would be "a resource record 285 owned by a wildcard domain name." 287 2.1.2 Asterisks and Other Characters 289 No label values other than that in section 2.1.1 are asterisk 290 labels, hence names beginning with other labels are never wildcard 291 domain names. Labels such as 'the*' and '**' are not asterisk 292 labels so these labels do not start wildcard domain names. 294 2.1.3 Non-terminal Wildcard Domain Names 296 In section 4.3.3, the following is stated: 298 # .......................... The owner name of the wildcard RRs is of 299 # the form "*.", where is any domain name. 300 # should not contain other * labels...................... 302 DNSEXT Working Group Expires September 13, 2006 [Page 6] 303 The restriction is now removed. The original documentation of it 304 is incomplete and the restriction does not serve any purpose 305 given years of operational experience. 307 There are three possible reasons for putting the restriction in 308 place, but none of the three has held up over time. One is 309 that the restriction meant that there would never be subdomains 310 of wildcard domain names, but the restriction as stated still 311 permits "example.*.example." for instance. Another is that 312 wildcard domain names are not intended to be empty non-terminals, 313 but this situation does not disrupt the algorithm in 4.3.2. 314 Finally, "nested" wildcard domain names are not ambiguous once 315 the concept of the closest encloser had been documented. 317 A wildcard domain name can have subdomains. There is no need 318 to inspect the subdomains to see if there is another asterisk 319 label in any subdomain. 321 A wildcard domain name can be an empty non-terminal. (See the 322 upcoming sections on empty non-terminals.) In this case, any 323 lookup encountering it will terminate as would any empty 324 non-terminal match. 326 2.2 Existence Rules 328 The notion that a domain name 'exists' is mentioned in the 329 definition of wildcards. In section 4.3.3 of RFC 1034: 331 # Wildcard RRs do not apply: 332 # 333 ... 334 # - When the query name or a name between the wildcard domain and 335 # the query name is know[n] to exist. For example, if a wildcard 337 "Existence" is therefore an important concept in the understanding 338 of wildcards. Unfortunately, the definition of what exists, in 339 RFC 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another 340 look is taken at the definition of existence. 342 2.2.1 An Example 344 To illustrate what is meant by existence consider this complete 345 zone: 347 DNSEXT Working Group Expires September 13, 2006 [Page 7] 348 $ORIGIN example. 349 example. 3600 IN SOA 350 example. 3600 NS ns.example.com. 351 example. 3600 NS ns.example.net. 352 *.example. 3600 TXT "this is a wildcard" 353 *.example. 3600 MX 10 host1.example. 354 sub.*.example. 3600 TXT "this is not a wildcard" 355 host1.example. 3600 A 192.0.2.1 356 _ssh._tcp.host1.example. 3600 SRV 357 _ssh._tcp.host2.example. 3600 SRV 358 subdel.example. 3600 NS ns.example.com. 359 subdel.example. 3600 NS ns.example.net. 361 A look at the domain names in a tree structure is helpful: 363 | 364 -------------example------------ 365 / / \ \ 366 / / \ \ 367 / / \ \ 368 * host1 host2 subdel 369 | | | 370 | | | 371 sub _tcp _tcp 372 | | 373 | | 374 _ssh _ssh 376 The following responses would be synthesized from one of the 377 wildcards in the zone: 379 QNAME=host3.example. QTYPE=MX, QCLASS=IN 380 the answer will be a "host3.example. IN MX ..." 382 QNAME=host3.example. QTYPE=A, QCLASS=IN 383 the answer will reflect "no error, but no data" 384 because there is no A RR set at '*.example.' 386 QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN 387 the answer will be "foo.bar.example. IN TXT ..." 388 because bar.example. does not exist, but the wildcard 389 does. 391 The following responses would not be synthesized from any of the 392 wildcards in the zone: 394 QNAME=host1.example., QTYPE=MX, QCLASS=IN 395 because host1.example. exists 397 QNAME=sub.*.example., QTYPE=MX, QCLASS=IN 398 because sub.*.example. exists 400 DNSEXT Working Group Expires September 13, 2006 [Page 8] 401 QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN 402 because _tcp.host1.example. exists (without data) 404 QNAME=host.subdel.example., QTYPE=A, QCLASS=IN 405 because subdel.example. exists (and is a zone cut) 407 QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN 408 because *.example. exists 410 The final example highlights one common misconception about 411 wildcards. A wildcard "blocks itself" in the sense that a 412 wildcard does not match its own subdomains. I.e. "*.example." 413 does not match all names in the "example." zone, it fails to 414 match the names below "*.example." To cover names under 415 "*.example.", another wildcard domain name is needed - 416 "*.*.example." - which covers all but its own subdomains. 418 2.2.2 Empty Non-terminals 420 Empty non-terminals [RFC2136, Section 7.16] are domain names 421 that own no resource records but have subdomains that do. In 422 section 2.2.1, "_tcp.host1.example." is an example of a empty 423 non-terminal name. Empty non-terminals are introduced by this 424 text in section 3.1 of RFC 1034: 426 # The domain name space is a tree structure. Each node and leaf on 427 # the tree corresponds to a resource set (which may be empty). The 428 # domain system makes no distinctions between the uses of the 429 # interior nodes and leaves, and this memo uses the term "node" to 430 # refer to both. 432 The parenthesized "which may be empty" specifies that empty non- 433 terminals are explicitly recognized, and that empty non-terminals 434 "exist." 436 Pedantically reading the above paragraph can lead to an 437 interpretation that all possible domains exist - up to the 438 suggested limit of 255 octets for a domain name [RFC1035]. 439 For example, www.example. may have an A RR, and as far as is 440 practically concerned, is a leaf of the domain tree. But the 441 definition can be taken to mean that sub.www.example. also 442 exists, albeit with no data. By extension, all possible domains 443 exist, from the root on down. 445 As RFC 1034 also defines "an authoritative name error indicating 446 that the name does not exist" in section 4.3.1, so this apparently 447 is not the intent of the original definition, justifying the 448 need for an updated definition in the next section. 450 DNSEXT Working Group Expires September 13, 2006 [Page 9] 451 2.2.3 Yet Another Definition of Existence 453 RFC1034's wording is fixed by the following paragraph: 455 The domain name space is a tree structure. Nodes in the tree 456 either own at least one RRSet and/or have descendants that 457 collectively own at least one RRSet. A node may exist with no 458 RRSets only if it has descendants that do; this node is an empty 459 non-terminal. 461 A node with no descendants is a leaf node. Empty leaf nodes do 462 not exist. 464 Note that at a zone boundary, the domain name owns data, 465 including the NS RR set. In the delegating zone, the NS RR 466 set is not authoritative, but that is of no consequence here. 467 The domain name owns data, therefore, it exists. 469 2.3 When is a Wildcard Domain Name Not Special 471 When a wildcard domain name appears in a message's query section, 472 no special processing occurs. An asterisk label in a query name 473 only matches a single, corresponding asterisk label in the 474 existing zone tree when the 4.3.2 algorithm is being followed. 476 When a wildcard domain name appears in the resource data of a 477 record, no special processing occurs. An asterisk label in that 478 context literally means just an asterisk. 480 3. Impact of a Wildcard Domain Name On a Response 482 RFC 1034's description of how wildcards impact response 483 generation is in its section 4.3.2. That passage contains the 484 algorithm followed by a server in constructing a response. 485 Within that algorithm, step 3, part 'c' defines the behavior of 486 the wildcard. 488 The algorithm in section 4.3.2. is not intended to be pseudo-code, 489 i.e., its steps are not intended to be followed in strict order. 490 The "algorithm" is a suggested means of implementing the 491 requirements. As such, in step 3, parts a, b, and c, do not have 492 to be implemented in that order, provided that the result of the 493 implemented code is compliant with the protocol's specification. 495 3.1 Step 2 497 Step 2 of section 4.3.2 reads: 499 # 2. Search the available zones for the zone which is the nearest 500 # ancestor to QNAME. If such a zone is found, go to step 3, 501 # otherwise step 4. 503 In this step, the most appropriate zone for the response is 504 chosen. The significance of this step is that it means all of 505 step 3 is being performed within one zone. This has significance 506 when considering whether or not an SOA RR can be ever be used for 507 synthesis. 509 3.2 Step 3 511 Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. 512 But the beginning of the step is important and needs explanation. 514 # 3. Start matching down, label by label, in the zone. The 515 # matching process can terminate several ways: 517 The word 'matching' refers to label matching. The concept 518 is based in the view of the zone as the tree of existing names. 519 The query name is considered to be an ordered sequence of 520 labels - as if the name were a path from the root to the owner 521 of the desired data. (Which it is - 3rd paragraph of RFC 1034, 522 section 3.1.) 524 The process of label matching a query name ends in exactly one of 525 three choices, the parts 'a', 'b', and 'c'. Either the name is 526 found, the name is below a cut point, or the name is not found. 528 Once one of the parts is chosen, the other parts are not 529 considered. (E.g., do not execute part 'c' and then change 530 the execution path to finish in part 'b'.) The process of label 531 matching is also done independent of the query type (QTYPE). 533 Parts 'a' and 'b' are not an issue for this clarification as they 534 do not relate to record synthesis. Part 'a' is an exact match 535 that results in an answer, part 'b' is a referral. 537 3.3 Part 'c' 539 The context of part 'c' is that the process of label matching the 540 labels of the query name has resulted in a situation in which 541 there is no corresponding label in the tree. It is as if the 542 lookup has "fallen off the tree." 544 # c. If at some label, a match is impossible (i.e., the 545 # corresponding label does not exist), look to see if [...] 546 # the "*" label exists. 548 To help describe the process of looking 'to see if [...] the "*" 549 label exists' a term has been coined to describe the last domain 550 (node) matched. The term is "closest encloser." 552 3.3.1 Closest Encloser and the Source of Synthesis 554 The closest encloser is the node in the zone's tree of existing 555 domain names that has the most labels matching the query name 556 (consecutively, counting from the root label downward). Each match 557 is a "label match" and the order of the labels is the same. 559 The closest encloser is, by definition, an existing name in the 560 zone. The closest encloser might be an empty non-terminal or even 561 be a wildcard domain name itself. In no circumstances is the 562 closest encloser to be used to synthesize records for the current 563 query. 565 The source of synthesis is defined in the context of a query 566 process as that wildcard domain name immediately descending 567 from the closest encloser, provided that this wildcard domain 568 name exists. "Immediately descending" means that the source 569 of synthesis has a name of the form: 570 .. 571 A source of synthesis does not guarantee having a RRSet to use 572 for synthesis. The source of synthesis could be an empty 573 non-terminal. 575 If the source of synthesis does not exist (not on the domain 576 tree), there will be no wildcard synthesis. There is no search 577 for an alternate. 579 The important concept is that for any given lookup process, there 580 is at most one place at which wildcard synthetic records can be 581 obtained. If the source of synthesis does not exist, the lookup 582 terminates, the lookup does not look for other wildcard records. 584 3.3.2 Closest Encloser and Source of Synthesis Examples 586 To illustrate, using the example zone in section 2.2.1 of this 587 document, the following chart shows QNAMEs and the closest 588 enclosers. 590 QNAME Closest Encloser Source of Synthesis 591 host3.example. example. *.example. 592 _telnet._tcp.host1.example. _tcp.host1.example. no source 593 _dns._udp.host2.example. host2.example. no source 594 _telnet._tcp.host3.example. example. *.example. 595 _chat._udp.host3.example. example. *.example. 596 foobar.*.example. *.example. no source 598 3.3.3 Type Matching 600 RFC 1034 concludes part 'c' with this: 602 # If the "*" label does not exist, check whether the name 603 # we are looking for is the original QNAME in the query 604 # or a name we have followed due to a CNAME. If the name 605 # is original, set an authoritative name error in the 606 # response and exit. Otherwise just exit. 607 # 608 # If the "*" label does exist, match RRs at that node 609 # against QTYPE. If any match, copy them into the answer 610 # section, but set the owner of the RR to be QNAME, and 611 # not the node with the "*" label. Go to step 6. 613 The final paragraph covers the role of the QTYPE in the lookup 614 process. 616 Based on implementation feedback and similarities between step 617 'a' and step 'c' a change to this passage has been made. 619 The change is to add the following text to step 'c' prior to the 620 instructions to "go to step 6": 622 If the data at the source of synthesis is a CNAME, and 623 QTYPE doesn't match CNAME, copy the CNAME RR into the 624 answer section of the response changing the owner name 625 to the QNAME, change QNAME to the canonical name in the 626 CNAME RR, and go back to step 1. 628 This is essentially the same text in step a covering the 629 processing of CNAME RRSets. 631 4. Considerations with Special Types 633 Sections 2 and 3 of this document discuss wildcard synthesis 634 with respect to names in the domain tree and ignore the impact 635 of types. In this section, the implication of wildcards of 636 specific types are discussed. The types covered are those 637 that have proven to be the most difficult to understand. The 638 types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and 639 "none," i.e., empty non-terminal wildcard domain names. 641 4.1 SOA RRSet at a Wildcard Domain Name 643 A wildcard domain name owning an SOA RRSet means that the 644 domain is at the root of the zone (apex). The domain can not 645 be a source of synthesis because that is, by definition, a 646 descendent node (of the closest encloser) and a zone apex is 647 at the top of the zone. 649 Although a wildcard domain name owning an SOA RRSet can never 650 be a source of synthesis, there is no reason to forbid the 651 ownership of an SOA RRSet. 653 E.g., given this zone: 654 $ORIGIN *.example. 655 @ 3600 IN SOA 656 3600 NS ns1.example.com. 657 3600 NS ns1.example.net. 658 www 3600 TXT "the www txt record" 660 A query for www.*.example.'s TXT record would still find the 661 "the www txt record" answer. The asterisk label only becomes 662 significant when section 4.3.2, step 3 part 'c' is in effect. 664 Of course, there would need to be a delegation in the parent 665 zone, "example." for this to work too. This is covered in the 666 next section. 668 4.2 NS RRSet at a Wildcard Domain Name 670 With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now 671 in place, the semantics of a wildcard domain name owning an 672 NS RRSet has come to be poorly defined. The dilemma relates to 673 a conflict between the rules for synthesis in part 'c' and the 674 fact that the resulting synthesis generates a record for which 675 the zone is not authoritative. In a DNSSEC signed zone, the 676 mechanics of signature management (generation and inclusion 677 in a message) have become unclear. 679 Salient points of the working group discussion on this topic is 680 summarized in section 4.2.1. 682 As a result of these discussion, there is no definition given for 683 wildcard domain names owning an NS RRSet. The semantics are 684 left undefined until there is a clear need to have a set defined, 685 and until there is a clear direction to proceed. Operationally, 686 inclusion of wildcard NS RRSets in a zone is discouraged, but 687 not barred. 689 4.2.1 Discarded Notions 691 Prior to DNSSEC, a wildcard domain name owning a NS RRSet 692 appeared to be workable, and there are some instances in which 693 it is found in deployments using implementations that support 694 this. Continuing to allow this in the specification is not 695 tenable with DNSSEC. The reason is that the synthesis of the 696 NS RRSet is being done in a zone that has delegated away the 697 responsibility for the name. This "unauthorized" synthesis is 698 not a problem for the base DNS protocol, but DNSSEC, in affirming 699 the authorization model for DNS exposes the problem. 701 Outright banning of wildcards of type NS is also untenable as 702 the DNS protocol does not define how to handle "illegal" data. 703 Implementations may choose not to load a zone, but there is no 704 protocol definition. The lack of the definition is complicated 705 by having to cover dynamic update [RFC 2136], zone transfers, 706 as well as loading at the master server. The case of a client 707 (resolver, caching server) getting a wildcard of type NS in 708 a reply would also have to be considered. 710 Given the daunting challenge of a complete definition of how to 711 ban such records, dealing with existing implementations that 712 permit the records today is a further complication. There are 713 uses of wildcard domain name owning NS RRSets. 715 One compromise proposed would have redefined wildcards of type 716 NS to not be used in synthesis, this compromise fell apart 717 because it would have required significant edits to the DNSSEC 718 signing and validation work. (Again, DNSSEC catches 719 unauthorized data.) 721 With no clear consensus forming on the solution to this dilemma, 722 and the realization that wildcards of type NS are a rarity in 723 operations, the best course of action is to leave this open-ended 724 until "it matters." 726 4.3 CNAME RRSet at a Wildcard Domain Name 728 The issue of a CNAME RRSet owned by a wildcard domain name has 729 prompted a suggested change to the last paragraph of step 3c of 730 the algorithm in 4.3.2. The changed text appears in section 731 3.3.3 of this document. 733 4.4 DNAME RRSet at a Wildcard Domain Name 735 Ownership of a DNAME [RFC2672] RRSet by a wildcard domain name 736 represents a threat to the coherency of the DNS and is to be 737 avoided or outright rejected. Such a DNAME RRSet represents 738 non-deterministic synthesis of rules fed to different caches. 739 As caches are fed the different rules (in an unpredictable 740 manner) the caches will cease to be coherent. ("As caches 741 are fed" refers to the storage in a cache of records obtained 742 in responses by recursive or iterative servers.) 744 For example, assume one cache, responding to a recursive 745 request, obtains the record: 746 "a.b.example. DNAME foo.bar.example.net." 747 and another cache obtains: 748 "b.example. DNAME foo.bar.example.net." 749 both generated from the record: 750 "*.example. DNAME foo.bar.example.net." 751 by an authoritative server. 753 The DNAME specification is not clear on whether DNAME records 754 in a cache are used to rewrite queries. In some interpretations, 755 the rewrite occurs, in some, it is not. Allowing for the 756 occurrence of rewriting, queries for "sub.a.b.example. A" may 757 be rewritten as "sub.foo.bar.tld. A" by the former caching 758 server and may be rewritten as "sub.a.foo.bar.tld. A" by the 759 latter. Coherency is lost, an operational nightmare ensues. 761 Another justification for a recommendation to avoid the use of 762 wildcard DNAME records is the observation that such a record 763 could synthesize a DNAME owned by "sub.foo.bar.example." and 764 "foo.bar.example." There is a restriction in the DNAME 765 definition that no domain exist below a DNAME-owning domain, 766 hence, the wildcard DNAME is to be avoided. 768 4.5 SRV RRSet at a Wildcard Domain Name 770 The definition of the SRV RRset is RFC 2782 [RFC2782]. In the 771 definition of the record, there is some confusion over the term 772 "Name." The definition reads as follows: 774 # The format of the SRV RR 775 ... 776 # _Service._Proto.Name TTL Class SRV Priority Weight Port Target 777 ... 778 # Name 779 # The domain this RR refers to. The SRV RR is unique in that the 780 # name one searches for is not this name; the example near the end 781 # shows this clearly. 783 Do not confuse the definition "Name" with the owner name. I.e., 784 once removing the _Service and _Proto labels from the owner name 785 of the SRV RRSet, what remains could be a wildcard domain name 786 but this is immaterial to the SRV RRSet. 788 E.g., If an SRV record is: 789 _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. 791 *.example is a wildcard domain name and although it is the Name 792 of the SRV RR, it is not the owner (domain name). The owner 793 domain name is "_foo._udp.*.example." which is not a wildcard 794 domain name. 796 A query for the SRV RRSet of "_foo._udp.bar.example." (class IN), 797 will result in a match of the name "*.example." (assuming there 798 is no bar.example.) and not a match of the SRV record shown. If 799 there is no SRV RRSet at "*.example." the answer section will 800 reflect that (be empty or a CNAME RRset). 802 The confusion is likely based on the mixture of the specification 803 of the SRV RR and the description of a "use case." 805 4.6 DS RRSet at a Wildcard Domain Name 807 A DS RRSet owned by a wildcard domain name is meaningless and 808 harmless. This statement is made in the context that an NS RRSet 809 at a wildcard domain name is undefined. At a non-delegation 810 point, a DS RRSet has no value (no corresponding DNSKEY RRSet 811 will be used in DNSSEC validation). If there is a synthesized 812 DS RRSet, it alone will not be very useful as it exists in the 813 context of a delegation point. 815 4.7 NSEC RRSet at a Wildcard Domain Name 817 Wildcard domain names in DNSSEC signed zones will have an NSEC 818 RRSet. Synthesis of these records will only occur when the 819 query exactly matches the record. Synthesized NSEC RR's will not 820 be harmful as they will never be used in negative caching or to 821 generate a negative response. [RFC2308] 823 4.8 RRSIG at a Wildcard Domain Name 825 RRSIG records will be present at a wildcard domain name in a 826 signed zone, and will be synthesized along with data sought in a 827 query. The fact that the owner name is synthesized is not a 828 problem as the label count in the RRSIG will instruct the 829 verifying code to ignore it. 831 4.9 Empty Non-terminal Wildcard Domain Name 833 If a source of synthesis is an empty non-terminal, then the 834 response will be one of no error in the return code and no RRSet 835 in the answer section. 837 5. Security Considerations 839 This document is refining the specifications to make it more 840 likely that security can be added to DNS. No functional 841 additions are being made, just refining what is considered 842 proper to allow the DNS, security of the DNS, and extending 843 the DNS to be more predictable. 845 6. IANA Considerations 847 None. 849 7. References 851 Normative References 853 [RFC20] ASCII Format for Network Interchange, V.G. Cerf, 854 Oct-16-1969 856 [RFC1034] Domain Names - Concepts and Facilities, 857 P.V. Mockapetris, Nov-01-1987 859 [RFC1035] Domain Names - Implementation and Specification, P.V 860 Mockapetris, Nov-01-1987 862 [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 864 [RFC2119] Key Words for Use in RFCs to Indicate Requirement 865 Levels, S Bradner, March 1997 867 [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), 868 M. Andrews, March 1998 870 [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, 871 August 1999. 873 [RFC2782] A DNS RR for specifying the location of services (DNS 874 SRV), A. Gulbrandsen, et.al., February 2000 876 [RFC3978] IETF Rights in Contributions, S. Bradner, March 2005 878 [RFC4033] DNS Security Introduction and Requirements, R. Arends, 879 et.al., March 2005 881 [RFC4034] Resource Records for the DNS Security Extensions, 882 R. Arends, et.al., March 2005 884 [RFC4035] Protocol Modifications for the DNS Security Extensions, 885 R. Arends, et.al., March 2005 887 Informative References 889 [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), 890 P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, 891 April 1997 893 8. Editor 895 Name: Edward Lewis 896 Affiliation: NeuStar 897 Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US 898 Phone: +1-571-434-5468 899 Email: ed.lewis@neustar.biz 901 As required by law, as stated in RFC 3978, Section 3.4, 902 subsection a [RFC3978], this section comprises an 903 "Authors Section." 905 Comments on this document can be sent to the editor or the mailing 906 list for the DNSEXT WG, namedroppers@ops.ietf.org. 908 9. Others Contributing to the Document 910 This document represents the work of a large working group. The 911 editor merely recorded its collective wisdom. 913 As required by law, as stated in RFC 3978, Section 3.4, 914 subsection a [RFC3978], this section comprises an 915 "Acknowledgements Section." 917 10. Trailing Boilerplate 919 Copyright (C) The Internet Society (2006). 921 This document is subject to the rights, licenses and restrictions 922 contained in BCP 78, and except as set forth therein, the authors 923 retain all their rights. 925 This document and the information contained herein are provided 926 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 927 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 928 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 929 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 930 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 931 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 932 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 934 Intellectual Property 936 The IETF takes no position regarding the validity or scope of 937 any Intellectual Property Rights or other rights that might 938 be claimed to pertain to the implementation or use of the 939 technology described in this document or the extent to which 940 any license under such rights might or might not be available; 941 nor does it represent that it has made any independent effort 942 to identify any such rights. Information on the procedures 943 with respect to rights in RFC documents can be found in BCP 78 944 and BCP 79. 946 Copies of IPR disclosures made to the IETF Secretariat and any 947 assurances of licenses to be made available, or the result of an 948 attempt made to obtain a general license or permission for the 949 use of such proprietary rights by implementers or users of this 950 specification can be obtained from the IETF on-line IPR 951 repository at http://www.ietf.org/ipr. The IETF invites any 952 interested party to bring to its attention any copyrights, 953 patents or patent applications, or other proprietary rights 954 that may cover technology that may be required to implement 955 this standard. Please address the information to the IETF at 956 ietf-ipr@ietf.org. 958 Acknowledgement 960 Funding for the RFC Editor function is currently provided by the 961 Internet Society. 963 Expiration 965 This document expires on or about September 13, 2006.