idnits 2.17.1 draft-lewis-dns-wildcard-clarify-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 1) being 599 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 58 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 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). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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: 'RFC1034' is mentioned on line 44, but not defined == Missing Reference: 'RFC2119' is mentioned on line 177, but not defined == Unused Reference: 'RFC 1034' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 490, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force E. Lewis 2 Internet-Draft ARIN 3 February 4, 2003 Expires: August 4, 2003 5 Clarifying the Role of Wild Card Domains 6 in the Domain Name System 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The definition of wild cards is recast from the original in RFC 1034, 32 in words that are more specific and in line with RFC 2119. This document 33 is meant to supplement the definition in RFC 1034 and to alter neither 34 the spirit nor intent of that definition. 36 1 Introduction 38 The first section of this document will give a crisp overview of what 39 is begin defined, as well as the motivation for what amounts to a 40 simple rewording of an original document. An example is included to 41 help orient the reader. 43 Wild card domain names are defined in Section 4.3.3. of RFC 1034 as 44 "instructions for synthesizing RRs." [RFC1034] The meaning of this is 45 that a specific, special domain name is used to construct responses in 46 instances in which the query name is not otherwise represented in a zone. 48 A wild card domain name has a specific range of influence on query names 49 (QNAMEs) within a given class, which is rooted at the domain name 50 containing the wild card label, and is limited by explicit entries, zone 51 cuts and empty non-terminal domains (see section 1.3 of this document). 53 Note that a wild card domain name has no special impact on the search 54 for a query type (QTYPE). If a domain name is found that matches the 55 QNAME (exact or a wild card) but the QTYPE is not found at that point, 56 the proper response is that there is no data available. The search 57 does not continue on to seek other wild cards that might match the QTYPE. 58 To illustrate, a wild card owning an MX RR does not 'cover' other names 59 in the zone that own an A RR. 61 Why is this document needed? Empirical evidence suggests that the 62 words in RFC 1034 are not clear enough. There exist a number of 63 implementations that have strayed from the definition. There also 64 exists a misconception of operators that the wild card can be used to 65 add a specific RR type to all names, such as the MX RR example listed 66 above. This document is also needed as input to efforts to extend 67 DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear 68 base specification has proven to result in extension documents that 69 have unpredictable consequences. (This is true in general, not just 70 for DNS.) 72 1.1 Existence 74 The notion that a domain name 'exists' will arise numerous times in this 75 discussion. RFC 1034 raises the issue of existence in a number of places, 76 usually in reference to non-existence and often in reference to processing 77 involving wild card domain names. RFC 1034 does contain algorithms that 78 describe how domain names impact the preparation of an answer and does 79 define wild cards as a means of synthesizing answers. 81 To help clarify the topic of wild cards, a positive definition of existence 82 is needed. To complicate matters, though, there needs to be a recognition 83 that existence is relative. To an authoritative server, a domain name 84 exists if the domain name plays a role following the algorithms of 85 preparing a response. To a resolver, a domain name exists if there is 86 any data available corresponding to the name. The difference between the 87 two is the synthesis of records according to a wild card. 89 For the purposes of this document, the point of view of an authoritative 90 server is adopted. A domain name is said to exist if it plays a role in 91 the execution of the algorithms in RFC 1034. 93 1.2 An Example 95 For example, consider this wild card domain name: *.example. Any query 96 name under example. is a candidate to be matched (answered) by this wild 97 card. Although any name is a candidate, not all queries will match. 99 To further illustrate this, consider this example: 101 $ORIGIN example. 102 @ IN SOA 103 NS 104 NS 105 * TXT "this is a wild card" 106 MX 10 mailhost.example. 107 host1 A 10.0.0.1 108 _ssh._tcp.host1 SRV 109 _ssh._tcp.host2 SRV 110 subdel NS 112 The following queries would be synthesized from the wild card: 113 QNAME=host3.example. QTYPE=MX, QCLASS=IN 114 the answer will be a "host.example. IN MX ..." 115 QNAME=host3.example. QTYPE=A, QCLASS=IN 116 the answer will be a "host.example. IN NXT ..." 117 because there is no A RR set at '*' 119 The following queries would not be synthesized from the wild card: 120 QNAME=host1.example., QTYPE=MX, QCLASS=IN 121 because host1.example. exists 122 QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN 123 because _tcp.host1.example. exists (without data) 124 QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN 125 because host2.example. exists (without data) 126 QNAME=host.subdel.example., QTYPE=A, QCLASS=IN 127 because subdel.example. exists and is a zone cut 129 To the server, the following domains are considered to exist in the zone: 130 *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, _ssh._tcp.host2, 131 and subdel. To a resolver, many more domains appear to exist via the 132 synthesis of the wild card. 134 1.3 Empty Non-terminals 136 Empty non-terminals are domain names that have no data but have 137 subdomains. This is defined in section 3.1 of RFC 1034: 139 # The domain name space is a tree structure. Each node and leaf on the 140 # tree corresponds to a resource set (which may be empty). The domain 141 # system makes no distinctions between the uses of the interior nodes and 142 # leaves, and this memo uses the term "node" to refer to both. 144 The parenthesized "which may be empty" specifies that empty non-terminals 145 are explicitly recognized. According to the definition of existence in 146 this document, empty non-terminals do exist at the server. 148 Carefully reading the above paragraph can lead to an interpretation that 149 all possible domains exist - up to the suggested limit of 255 octets for 150 a domain name [RFC 1035]. For example, www.example. may have an A RR, and 151 as far as is practically concerned, is a leaf of the domain tree. But the 152 definition can be taken to mean that sub.www.example. also exists, albeit 153 with no data. By extension, all possible domains exist, from the root 154 down. As RFC 1034 also defines "an authoritative name error indicating 155 that the name does not exist" in section 4.3.1, this is not the intent 156 of the original document. 158 RFC1034's wording is to be clarified by adding the following paragraph: 160 A node is considered to have an impact on the algorithms of 4.3.2 161 if it is a leaf node with any resource sets or an interior node, 162 with or without a resource set, that has a subdomain that is a leaf 163 node with a resource set. A QNAME and QCLASS matching an existing 164 node never results in a response return code of authoritative name 165 error. 167 As an aside, an "authoritative name error" has been called NXDOMAIN in 168 some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned 169 to such an error by at least one implementation of DNS. 171 1.3 Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in the document entitled 176 "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] 178 Requirements are denoted by paragraphs that begin with with the following 179 convention: 'R'.. 181 2 Defining the Wild Card Domain Name 183 A wild card domain name is defined by having the initial label be: 185 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) 187 This defines domain names that may play a role in being a wild card, that 188 is, being a source for synthesized answers. Domain names conforming to 189 this definition that appear in queries and RDATA sections do not have 190 any special role. These cases will be described in more detail in 191 following sections. 193 R2.1 A domain name that is to be interpreted as a wild card MUST begin 194 with a label of '0000 0001 0010 1010' in binary. 196 The first octet is the normal label type and length for a 1 octet long 197 label, the second octet is the ASCII representation [RFC 20] for the 198 '*' character. In RFC 1034, ASCII encoding is assumed to be the character 199 encoding. 201 In the master file formats used in RFCs, a "*" is a legal representation 202 for the wild card label. Even if the "*" is escaped, it is still 203 interpreted as the wild card when it is the only character in the label. 205 R2.2. A server MUST treat a wild card domain name as the basis of 206 synthesized answers regardless of any "escape" sequences in 207 the input format. 209 RFC 1034 and RFC 1035 ignore the case in which a domain name might be 210 "the*.example.com." The interpretation is that this domain name in a 211 zone would only match queries for "the*.example.com" and not have any 212 other role. 214 Note: By virtue of this definition, a wild card domain name may have a 215 subdomain. The subdomain (or sub-subdomain) itself may also be a wild 216 card. E.g., *.*.example. is a wild card, so is *.sub.*.example. 217 More discussion on this is given in Appendix A. 219 3 Defining Existence 221 As described in the Introduction, a precise definition of existence is 222 needed. 224 R3.1 An authoritative server MUST treat a domain name as existing during 225 the execution of the algorithms in RFC 1034 when the domain name 226 conforms to the following definition. A domain name is defined 227 to exist if the domain name owns data and/or has a subdomain that 228 exists. 230 Note that at a zone boundary, the domain name owns data, including the 231 NS RR set. At the delegating server, the NS RR set is not authoritative, 232 but that is of no consequence here. The domain name owns data, therefore, 233 it exists. 235 R3.2 An authoritative server MUST treat a domain name that has neither 236 a resource record set nor a subdomain as nonexistent when executing 237 the algorithm in section 4.3.2. of RFC 1034. 239 4 Impact of a Wild Card Domain In a Query Message 241 When a wild card domain name appears in a question, e.g., the query name 242 is "*.example.", the response in no way differs from any other query. 243 In other words, the wild card label in a QNAME has no special meaning, 244 and query processing will proceed using '*' as a literal query name. 246 R4.1 A wild card domain name acting as a QNAME MUST be treated as any 247 other QNAME, there MUST be no special processing accorded it. 249 If a wild card domain name appears in the RDATA of a CNAME RR or any 250 other RR that has a domain name in it, the same rule applies. In the 251 instance of a CNAME RR, the wild card domain name is used in the same 252 manner of as being the original QNAME. For other RR's, rules vary 253 regarding what is done with the domain name(s) appearing in them, 254 in no case does the wild card hold special meaning. 256 R4.2 A wild card domain name appearing in any RR's RDATA MUST be treated 257 as any other domain name in that situation, there MUST be no special 258 processing accorded it. 260 5 Impact of a Wild Card Domain On a Response 262 The description of how wild cards impact response generation is in RFC 263 1034, section 4.3.2. That passage contains the algorithm followed by a 264 server in constructing a response. Within that algorithm step 3, part 265 'c' defines the behavior of the wild card. The algorithm is directly 266 quoted in lines that begin with a '#' sign. Commentary is interleaved. 268 [Note that are no requirements specifically listed in this section. The 269 text here is explanatory and interpretative. There is no change to 270 the algorithm specified in RFC 1034.] 272 The context of part 'c' is that the search is progressing label by label 273 through the QNAME. (Note that the data being searched is the authoritative 274 data in the server, the cache is searched in step 4.) Step 3's part 'a' 275 covers the case that the QNAME has been matched in full, regardless of the 276 presence of a CNAME RR. Step 'b' covers crossing a cut point, resulting 277 in a referral. All that is left is to look for the wild card. 279 Step 3 of the algorithm also assumes that the search is looking in the 280 zone closest to the answer, i.e., in the same class as QCLASS and as 281 close to the authority as possible on this server. If the zone is not 282 the authority, then a referral is given, possibly one indicating lameness. 284 # c. If at some label, a match is impossible (i.e., the 285 # corresponding label does not exist), look to see if a 286 # the "*" label exists. 288 The above paragraph refers to finding the domain name that exists in the 289 zone and that most encloses the QNAME. Such a domain name will mark the 290 boundary of candidate wild card domain names that might be used to 291 synthesize an answer. (Remember that at this point, if the most enclosing 292 name is the same as the QNAME, part 'a' would have recorded an exact 293 match.) The existence of the enclosing name means that no wild card name 294 higher in the tree is a candidate to answer the query. 296 Once the closest enclosing node is identified, there's the matter of what 297 exists below it. It may have subdomains, but none will be closer to the 298 QNAME. One of the subdomains just might be a wild card. If it exists, 299 this is the only wild card eligible to be used to synthesize an answer 300 for the query. Even if the closest enclosing node conforms to the syntax 301 rule in section 2 for being a wild card domain name, the closest enclosing 302 node is not eligible to be a source of a synthesized answer. 304 The only wild card domain name that is a candidate to synthesize an answer 305 will be the "*" subdomain of the closest enclosing domain name. Three 306 possibilities can happen. The "*" subdomain does not exist, the "*" 307 subdomain does but does not have an RR set of the same type as the QTYPE, 308 or it exists and has the desired RR set. 310 For the sake of brevity, the closest enclosing node can be referred to as 311 the "closest encloser." 313 To illustrate, using the example in section 1.2 of this document, the 314 following chart shows QNAMEs and the closest enclosers. In Appendix A 315 there is another chart showing unusual cases. 317 QNAME Closest Encloser Wild Card Source 318 host3.example. example. *.example. 319 _telnet._tcp.host1.example. _tcp.host1.example. no wild card 320 _telnet._tcp.host2.example. host2.example. no wild card 321 _telnet._tcp.host3.example. example. *.example. 322 _chat._udp.host3.example. example. *.example. 324 Note that host1.subdel.example. is in a subzone, so the search for it ends 325 in a referral in part 'b', thus does not enter into finding a closest 326 encloser. 328 The fact that a closest encloser will be the only superdomain that 329 can have a candidate wild card will have an impact when it comes to 330 designing authenticated denial of existence proofs. (This concept 331 is not introduced until DNS Security Extensions are considered in 332 upcoming sections.) 334 # If the "*" label does not exist, check whether the name 335 # we are looking for is the original QNAME in the query 336 # or a name we have followed due to a CNAME. If the name 337 # is original, set an authoritative name error in the 338 # response and exit. Otherwise just exit. 340 The above passage says that if there is not even a wild card domain name 341 to match at this point (failing to find an explicit answer elsewhere), 342 we are to return an authoritative name error at this point. If we were 343 following a CNAME, the specification is unclear, but seems to imply that 344 a no error return code is appropriate, with just the CNAME RR (or sequence 345 of CNAME RRs) in the answer section. 347 # If the "*" label does exist, match RRs at that node 348 # against QTYPE. If any match, copy them into the answer 349 # section, but set the owner of the RR to be QNAME, and 350 # not the node with the "*" label. Go to step 6. 352 This final paragraph covers the role of the QTYPE in the process. Note 353 that if no resource record set matches the QTYPE the result is that no data 354 is copied, but the search still ceases ("Go to step 6."). 356 6 Authenticated Denial and Wild Cards 358 In unsecured DNS, the only concern when there is no data to return to 359 a query is whether the domain name from which the answer comes exists or 360 not, whether or not a name error is indicated in the return code. In 361 either case the answer section is empty or contained just a sequence of 362 CNAME RR sets. 364 In securing DNS, authenticated denial of existence is a service that is 365 provided. The chosen solution to provide this service is to generate 366 resource records indicating what is protected in a zone and to digitally 367 sign these. 369 The resource records that do this, as defined in RFC 2535, are NXT RRs. 371 There are three points to consider when clarifying the topic of wild card 372 domain names. One is the construction of the records. The second is 373 the inclusion of records in responses. The third is the interpretation 374 of the records in a response by the resolver. 376 6.1 Preparing Wild Card Domain Name Owned Non-existence Proofs 378 During the creation of the authenticated denial records, the wild card 379 domain name plays no special role, in the same manner as the wild card 380 domain name playing no special role in a query. 382 There is one consideration with regards to preparing non-existence 383 proofs. 385 R6.1 Any mechanism used to provide authenticated denial MUST reveal the 386 closest enclosing existing domain for the query. If this is not 387 provided, the resolver will not be able to ascertain the identity 388 of an appropriate wild card domain name. 390 6.2 Role of Wild Cards in Answers 392 There are three cases to address. The first is synthesizing from wild card 393 domain name with data, the second is negatively synthesizing from an 394 existing wild card, and the third is denying that neither an exact match, 395 referral, nor wild card exist to answer the query. 397 6.2.1 Synthesizing From a Wild Card 399 When preparing an answer from a wild card domain name, the answer needs 400 to include proof that the exact match of the QNAME and QCLASS does not 401 exist. This is needed because synthesis of the answer replaces the "*" 402 label with the QNAME without securing the result. The resolver will 403 realize that the answer was derived from a wild card, but cannot 404 detect whether an exact match was maliciously omitted. 406 R6.2 When synthesizing a positive answer from a wild card domain name, the 407 answer MUST include proof that the exact match for the QNAME and 408 QCLASS does not exist. 410 6.2.2. Synthesizing Negatively From a Wild Card 412 When synthesizing a negative answer that is derived from a wild card, 413 meaning that a wild card matched the QNAME (no exact match happened for 414 QNAME) but that there is no match for QTYPE there, two negative answers 415 are needed, possibly one. As in 6.2.1, a proof that the exact match 416 failed is needed. A second proof is needed to show that the wild card 417 domain name does not have the QTYPE. Depending on the method of 418 authenticated denial, these this could be possible with one statement. 420 R6.3 When synthesizing a negative answer from a wild card domain name, 421 the answer MUST include proof that the exact match of the QNAME 422 and QCLASS does not exist and that the QTYPE matches no RR set at 423 the wild card. If this answer can be optimized, an implementation 424 SHOULD reduce the number of records included in the response. 426 6.2.3. Answering With an Authoritative Name Error 428 When answering with a result code of a name error, the answer needs to 429 provide proof that neither the exact match for QNAME and QCLASS exists 430 nor that a wild card domain name exists as a subdomain of the closest 431 enclosing domain name. 433 R6.4 When preparing a reply with an authoritative name error, the answer 434 MUST include proof that the exact match for the QNAME and QCLASS 435 does not exist and that no wild card is available to provide a match. 437 6.2.4. The Remaining Case 439 When answering negatively because there is a match for QNAME and QCLASS 440 but no match for the QTYPE, only a proof for that is needed. Just as 441 the search does not proceed onto a search for the wild card in this 442 case, neither does the construction of the negative answer proof. 444 R6.5 When preparing a reply in which there is an exact match of the 445 QNAME and QCLASS, but there is no RR set matching the QTYPE, 446 the reply SHOULD NOT contain any proof regarding the wild card 447 domain name. 449 6.3 Interpreting Negative Answers Involving Wild Cards 451 There are two requirements for resolvers when it comes to handling 452 negative answers generated as described in section 6.2. 454 R6.6 A resolver MUST be able to identify negative answer data that 455 indicate when a match for QNAME and QCLASS does not exist. 457 R6.7 From a negative answer, a resolver MUST be able to determine 458 the closest enclosing domain name in a negative answer and 459 MUST be able to process a negative answer involving the one 460 wild card domain name that is a candidate to provide a 461 synthesized answer. 463 6.4 Authenticated Denial, Wild Card Domain Names, and Opt-In 465 When considering the Opt-In proposal [WIP], it is wise to not combine 466 a zone that adheres to both opt-in and that has a wild card domain 467 name. The reason is rooted in that the synthesis of an answer is done 468 by substituting the QNAME for the wild card domain name in the answer. 469 Because this is unsecured, and the is ambiguity regarding whether a 470 negative proof can be provided for the exact match (when it is outside 471 the opt-in secured area), a definitive proof of authenticated denial 472 is not possible. 474 7 Security Considerations 476 This document is refining the specifications to make it more likely that 477 security can be added to DNS. No functional additions are being made, 478 just refining what is considered proper to allow the system, security 479 of the system, and extending the system more predictable. 481 8 References 483 Normative References 485 [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 486 [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, 487 Nov-01-1987 488 [RFC 1035] Domain Names - Implementation and Specification, P.V 489 Mockapetris, Nov-01-1987 490 [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S 491 Bradner, March 1997 493 Non-normative References 495 [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, 496 Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 497 [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 498 [WIP] DNSSEC Opt-In, Internet Draft, R. Arends, M. Kosters, D. Blacka, 2002 500 9 Other Contributing to This Document 502 Others who have directly caused text to appear in the document: Paul Vixie 503 and Olaf Kolkman. Many others have indirect influences on the content. 505 10 Editor 507 Name: Edward Lewis 508 Title: Research Engineer 509 Affiliation: ARIN 510 Email: edlewis@arin.net 511 Phone: +1-703-227-9854 513 Appendix A: Subdomains of Wild Card Domain Names 515 In reading the definition of section 2 carefully, it is possible to 516 rationalize unusual names as legal. In the example given, *.example. 517 could have subdomains of *.sub.*.example. and even the more direct 518 *.*.example. (The implication here is that these domain names own 519 explicit resource records sets.) Although defining these names is not 520 easy to justify, it is important that implementations account for the 521 possibility. This section will give some further guidance on handling 522 these names. 524 The first thing to realize is that by all definitions, subdomains of 525 wild card domain names are legal. In analyzing them, one realizes 526 that they cause no harm by their existence. Because of this, they are 527 allowed to exist, i.e., there are no special case rules made to disallow 528 them. The reason for not preventing these names is that the prevention 529 would just introduce more code paths to put into implementations. 531 The concept of "closest enclosing" existing names is important to keep in 532 mind. It is also important to realize that a wild card domain name can 533 be a closest encloser of a query name. For example, if *.*.example. is 534 defined in a zone, and the query name is a.*.example., then the closest 535 enclosing domain name is *.example. Keep in mind that the closest 536 encloser is not eligible to be a source of synthesized answers, just the 537 subdomain of it that has the first label "*". 539 To illustrate this, the following chart shows some matches. Assume that 540 the names *.example., *.*.example., and *.sub.*.example. are defined 541 in the zone. 543 QNAME Closest Encloser Wild Card Source 544 a.example. example. *.example. 545 b.a.example. example. *.example. 546 a.*.example. *.example. *.*.example. 547 b.a.*.example. *.example. *.*.example. 548 b.a.*.*.example. *.*.example. no wild card 549 a.sub.*.example. sub.*.example. *.sub.*.example. 550 b.a.sub.*.example. sub.*.example. *.sub.*.example. 551 a.*.sub.*.example. *.sub.*.example. no wild card 552 *.a.example. example. *.example. 553 a.sub.b.example. example. *.example. 555 Recall that the closest encloser itself cannot be the wild card. Therefore 556 the match for b.a.*.*.example. has no applicable wild card. 558 Finally, if a query name is sub.*.example., any answer available will come 559 from an exact name match for sub.*.example. No wild card synthesis is 560 performed in this case. 562 Full Copyright Statement 564 Copyright (C) The Internet Society 2003. All Rights Reserved. 566 This document and translations of it may be copied and furnished to 567 others, and derivative works that comment on or otherwise explain it 568 or assist in its implementation may be prepared, copied, published and 569 distributed, in whole or in part, without restriction of any kind, 570 provided that the above copyright notice and this paragraph are 571 included on all such copies and derivative works. However, this 572 document itself may not be modified in any way, such as by removing 573 the copyright notice or references to the Internet Society or other 574 Internet organizations, except as needed for the purpose of developing 575 Internet standards in which case the procedures for copyrights defined 576 in the Internet Standards process must be followed, or as required to 577 translate it into languages other than English. 579 The limited permissions granted above are perpetual and will not be 580 revoked by the Internet Society or its successors or assigns. 582 This document and the information contained herein is provided on an 583 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 584 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 585 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 586 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 587 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Acknowledgement 591 Funding for the RFC Editor function is currently provided by the 592 Internet Society. 594 -- 595 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 596 Edward Lewis +1-703-227-9854 597 ARIN Research Engineer