From 950e096eca06a90b832b56fe1657e9c1427b5998 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 6 Feb 2003 04:55:13 +0000 Subject: [PATCH] new draft --- ...t => draft-ietf-dnsext-insensitive-01.txt} | 290 ++++++--- .../draft-lewis-dns-wildcard-clarify-00.txt | 599 ++++++++++++++++++ 2 files changed, 802 insertions(+), 87 deletions(-) rename doc/draft/{draft-ietf-dnsext-insensitive-00.txt => draft-ietf-dnsext-insensitive-01.txt} (63%) create mode 100644 doc/draft/draft-lewis-dns-wildcard-clarify-00.txt diff --git a/doc/draft/draft-ietf-dnsext-insensitive-00.txt b/doc/draft/draft-ietf-dnsext-insensitive-01.txt similarity index 63% rename from doc/draft/draft-ietf-dnsext-insensitive-00.txt rename to doc/draft/draft-ietf-dnsext-insensitive-01.txt index d6a85ccac9..77e9c9df46 100644 --- a/doc/draft/draft-ietf-dnsext-insensitive-00.txt +++ b/doc/draft/draft-ietf-dnsext-insensitive-01.txt @@ -1,13 +1,13 @@ INTERNET-DRAFT Donald E. Eastlake 3rd Clarifies STD0013 Motorola Laboratories -Expires July 2003 January 2003 +Expires August 2003 February 2003 Domain Name System (DNS) Case Insensitivity Clarification ------ ---- ------ ----- ---- ------------- ------------- - + Donald E. Eastlake 3rd @@ -60,42 +60,42 @@ D. Eastlake 3rd [Page 1] INTERNET-DRAFT DNS Case Insensitivity +Acknowledgements + + The contributions to this document of Rob Austein, Olafur + Gudmundsson, Daniel J. Anderson, Alan Barrett, and Andrew Main are + gratefully acknowledged. + + + Table of Contents Status of This Document....................................1 Abstract...................................................1 + Acknowledgements...........................................2 Table of Contents..........................................2 1. Introduction............................................3 2. Case Insensitivity of DNS Labels........................3 - 3. Additional DNS Case Insensitivity Considerations........4 - 3.1 CLASS Case Insensitivity Considerations................4 - 3.2 Label Type Case Insensitivity Considerations...........5 - 4. Case on Input and Output................................5 - 5. Security Considerations.................................6 - - Normative References.......................................7 - Informative References.....................................7 - - Author's Address...........................................8 - Expiration and File Name...................................8 - - - - - - - - - - - - - - + 2.1 Escaping Unusual DNS Label Octets......................3 + 2.2 Example Labels with Escapes............................4 + 2.3 Name Lookup Case Insensitivity.........................4 + 2.4 Original DNS Label Types...............................5 + 3. Additional DNS Case Insensitivity Considerations........5 + 3.1 CLASS Case Insensitivity Considerations................5 + 3.2 Extended Label Type Case Insensitivity Considerations..5 + 4. Case on Input and Output................................6 + 4.1 DNS Output Case Preservation...........................6 + 4.2 DNS Input Case Preservation............................6 + 4.3 Wildcard Matching......................................7 + 5. Security Considerations.................................7 + Normative References.......................................9 + Informative References.....................................9 + Author's Address..........................................10 + Expiration and File Name..................................10 @@ -123,7 +123,7 @@ INTERNET-DRAFT DNS Case Insensitivity The Domain Name System (DNS) is the global hierarchical replicated distributed database system for Internet addressing, mail proxy, and other information. Each node in the DNS tree has a name consisting of - zero or more labels [STD 13][RFC 1591, 2606] which have always been + zero or more labels [STD 13][RFC 1591, 2606] which have been specified as being treated in a case insensitive fashion. This document clarifies the meaning of "case insensitive" for this application. @@ -153,21 +153,21 @@ INTERNET-DRAFT DNS Case Insensitivity WWW.gnu.AI.mit.EDU. or 69.2.0.192.in-ADDR.ARPA. - The individual bytes of which DNS names consist are not limited to + The individual octets of which DNS names consist are not limited to valid ASCII character codes. They are defined as 8-bit bytes and all - values are allowed. It is just that they are traditionally interpreted + values are allowed. Most applications, however, interprete them as ASCII characters. - The typographic convention for bytes that do not correspond to an - ASCII printing graphic is to show them as a back-slash followed by - three hex digits for the value of the byte as an unsigned - integer. This includes all byte values outside of the inclusive range - of 0x21 ("!") to 0x7E ("~"). That is to say, all byte values in the - two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. The same - convention can be used for the back-slash character and the special - label separator period ("."). A period can also be protected from - recognition as a separator, so that it will be treated as a normal - label character, by preceeding it with a back-slash. The first example + + +2.1 Escaping Unusual DNS Label Octets + + An escape is needed for all octet values outside of the inclusive + range of 0x21 ("!") to 0x7E ("~"). That is to say, all octet values in + the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. + + One typographic convention for octets that do not correspond to an + ASCII printing graphic is to show them as a back-slash followed by the D. Eastlake 3rd [Page 3] @@ -176,41 +176,90 @@ D. Eastlake 3rd [Page 3] INTERNET-DRAFT DNS Case Insensitivity - below shows embedded spaces and a period (".") within a label. The - second one show a 4 byte label where the second byte has all bits zero - and the third byte has all bits one. + value of the octet as an unsigned integer represented by exactly three + decimal digits. The same convention can be used for printing ASCII + characters. This includes the back-slash character used in this + convention itself and the special label separator period (".") which + can be expressed as \092 and \046 respectively. - Donald\040E\.\040Eastlake\0403rd.example. - or a\000\377z.example. + A back-slash followed by only one or two decimal digits is + undefined. A back-slash followed by four decimal digits produces two + octets, the first octet having the value of the first three digits + considered as a decimal number and the second octet being the + character code for the fourth decimal digit. + + Octets, other than those corresponding to the ASCII digits 0 through + 9, can also be protected from recognition, so that they will be + treated as a normal label character, by a second convention: + preceding them with a back-slash. This is the most commonly used + technique for protecting back slash ("\") and period ("."). However, + it is advisable to avoid using this on other than printing ASCII + characters. + + + +2.2 Example Labels with Escapes + + The first example below shows embedded spaces and a period (".") + within a label. The second one show a 4 octet label where the second + octet has all bits zero and the third octet has all bits one. + + Donald\032E\.\032Eastlake\0323rd.example. + or a\000\255z.example. + + + +2.3 Name Lookup Case Insensitivity The design decision was made that comparisons on name lookup for DNS queries should be case insensitive [STD 13]. That is to say, a lookup - string byte with a value in the inclusive range of 0x41 to 0x5A, the + string octet with a value in the inclusive range of 0x41 to 0x5A, the upper case ASCII letters, MUST match the identical value and also match the corresponding value in the inclusive range 0x61 to 0x7A, - the lower case ASCII letters. And a lookup string byte with a lower + the lower case ASCII letters. And a lookup string octet with a lower case ASCII letter value MUST similarly match the identical value and also match the corresponding value in the upper case ASCII letter - range. One way to implement this rule would be, when comparing bytes, - to subtract 0x20 from all bytes in the inclusive range 0x61 to 0x7A - before the comparison. Such an operation is commonly known as "case - folding". + range. - (Historic Note: the terms "upper case" and "lower case" were invented - after movable type became wide spread for printing. The terms - originally refered to the two font trays for storing, in partitioned - areas, the different physical type elements. Before movable type, - the nearest equivalent terms were "majuscule" and "minuscule".) + (Historical Note: the terms "upper case" and "lower case" were + invented after movable type became wide spread for printing. The + terms originally referred to the two font trays for storing, in + partitioned areas, the different physical type elements. Before + movable type, the nearest equivalent terms were "majuscule" and + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + "minuscule".) + + One way to implement this rule would be, when comparing octets, to + subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A + before the comparison. Such an operation is commonly known as "case + folding" but implementation via case folding is not required. Note + that the DNS case insensitivity does NOT correspond to the case + folding specified in iso-8859-1 or iso-8859-2. For example, the + octets 0xDD (\221) and 0xFD (\253) do NOT match although in other + contexts where they are interpreted as the upper and lower case + version of "Y" with an acute accent, they might. + + + +2.4 Original DNS Label Types DNS labels in wire encoded names have a type associated with them. The original DNS standard [RFC 1035] had only two types. ASCII - labels, with a length of from zero to 63 bytes and indirect labels + labels, with a length of from zero to 63 octets and indirect labels which consist of an offset pointer to a name location elsewhere in - the wire encoding. (The ASCII label of length zero is reserved for - use as the name of the root node of the name tree.) ASCII labels - follow the ASCII case conventions described above. Indirect labels - are, in effect, replaced by the name to which they point which is - then treated with the case insensitivity rules in this document. + the wire encoding on a DNS message. (The ASCII label of length zero + is reserved for use as the name of the root node of the name tree.) + ASCII labels follow the ASCII case conventions described above. + Indirect labels are, in effect, replaced by the name to which they + point which is then treated with the case insensitivity rules in this + document. @@ -227,21 +276,22 @@ INTERNET-DRAFT DNS Case Insensitivity for data location called CLASS. The only CLASS in global use at this time is the "IN" or Internet CLASS. + The handling of DNS label case is not CLASS dependent. -D. Eastlake 3rd [Page 4] + + +3.2 Extended Label Type Case Insensitivity Considerations + + DNS was extended by [RFC 2671] to have additional label type numbers + available. (The only such type defined so far it the BINARY type [RFC + + +D. Eastlake 3rd [Page 5] INTERNET-DRAFT DNS Case Insensitivity - The handling of DNS label case is not CLASS dependent. - - - -3.2 Label Type Case Insensitivity Considerations - - DNS was extended by [RFC 2671] to have additional label type numbers - available. (The only such type defined so far it the BINARY type [RFC 2673].) The ASCII case insensitivity conventions, or case folding, only apply @@ -256,11 +306,15 @@ INTERNET-DRAFT DNS Case Insensitivity preserved on output, except when output is optimized by the use of indirect labels, and preserved when possible on input. + + +4.1 DNS Output Case Preservation + [STD 13] views the DNS namespace as a node tree. ASCII output is as if a name was marshalled by taking the label on the node whose name - is to be output, converting it to a typographicly encoded ASCII + is to be output, converting it to a typographically encoded ASCII string, walking up the tree outputting each label encountered, and - preceeding all labels but the first with a period ("."). Wire output + preceding all labels but the first with a period ("."). Wire output follows the same sequence but each label is wire encoded and no periods inserted. No "case conversion" or "case folding" is done during such output operations. However, to optimize output, indirect @@ -271,6 +325,10 @@ INTERNET-DRAFT DNS Case Insensitivity destroy the output preservation of case. This type of optimization is commonly called "name compression". + + +4.2 DNS Input Case Preservation + Originally, DNS input came from an ASCII Master File as defined in [STD 13]. DNS Dynamic update has been added as a source of DNS data [RFC 2136, 3007]. When a node in the DNS name tree is created by such @@ -278,33 +336,44 @@ INTERNET-DRAFT DNS Case Insensitivity preserved if they are for nodes being creted. However, no change is made in the name label on nodes that already exist is the DNS data being augmented or updated. It is quite common for higher level nodes - to already exist. For example, if data with owner name - "foo.bar.example" is input and then later data with owner name - "xyz.BAR.example" is input, the name of the label on the - "bar.example" node, i.e. "bar", is not changed to "BAR". Thus later - retrieval of data stored under "xyz.bar.example" in this case can - easily result is obtaining data with "xyz.BAR.example". + to already exist. + + For example, if data with owner name "foo.bar.example" is input and + then later data with owner name "xyz.BAR.example" is input, the name + of the label on the "bar.example" node, i.e. "bar", is not changed to + "BAR". Thus later retrieval of data stored under "xyz.bar.example" in -D. Eastlake 3rd [Page 5] +D. Eastlake 3rd [Page 6] INTERNET-DRAFT DNS Case Insensitivity + this case can easily result is obtaining data with "xyz.BAR.example". + The same considerations apply inputting multiple data records with + owner names differing only in case. From the example above, if an "A" + record is stored under owner name "xyz.BAR.example" and then a second + "A" record under "XYZ.BAR.example", the second will be stored at the + node with the first (lower case initial label) name. + Note that the order of insertion into a server database of the DNS name tree nodes that appear in a Master File is not defined so that the results of inconsistent capitalization in a Master File are unpredicatable output capitalization. - There is one additional instance of note, which relfects the general + + +4.3 Wildcard Matching + + There is one additional instance of note, which reflects the general rules that output case reflects input case unless there is conflicting capitalization in the DNS database or the output case is hidden by name compression. This is when a query matches a wild card in the DNS database at a server. In that case, the answer SHOULD reflect the input case of the label or labels that matched the wildcard unless they are replaced by an indirect label which MAY - point to a name with different captialization. + point to a name with different capitalization. @@ -326,6 +395,23 @@ INTERNET-DRAFT DNS Case Insensitivity canonical ordering for them) appears in Section 8 of [RFC 2535]. See also [UNKRR]. + Finally, a non-DNS name may be stored into DNS with the false + expectation that case will always be preserved. For example, although + this would be quite rare, on a system with case sensitive email + address local parts, an attempt to store two "RP" records that + differed only in case would probably produce unexpected results that + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS Case Insensitivity + + + might have security implications. That is because the entire email + address, including the possibly case sensitive local or left hand + part, is encoded into a DNS name in a readable fashion where the case + of some letters might be changed on output as described above. @@ -344,7 +430,37 @@ INTERNET-DRAFT DNS Case Insensitivity -D. Eastlake 3rd [Page 6] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] INTERNET-DRAFT DNS Case Insensitivity @@ -402,7 +518,7 @@ Informative References -D. Eastlake 3rd [Page 7] +D. Eastlake 3rd [Page 9] INTERNET-DRAFT DNS Case Insensitivity @@ -424,9 +540,9 @@ Author's Address Expiration and File Name - This draft expires July 2003. + This draft expires August 2003. - Its file name is draft-ietf-dnsext-insensitive-00.txt. + Its file name is draft-ietf-dnsext-insensitive-01.txt. @@ -460,5 +576,5 @@ Expiration and File Name -D. Eastlake 3rd [Page 8] +D. Eastlake 3rd [Page 10] diff --git a/doc/draft/draft-lewis-dns-wildcard-clarify-00.txt b/doc/draft/draft-lewis-dns-wildcard-clarify-00.txt new file mode 100644 index 0000000000..bf5cab20d6 --- /dev/null +++ b/doc/draft/draft-lewis-dns-wildcard-clarify-00.txt @@ -0,0 +1,599 @@ + +Internet Engineering Task Force E. Lewis +Internet-Draft ARIN +February 4, 2003 Expires: August 4, 2003 + + Clarifying the Role of Wild Card Domains + in the Domain Name System + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress". + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Abstract + +The definition of wild cards is recast from the original in RFC 1034, +in words that are more specific and in line with RFC 2119. This document +is meant to supplement the definition in RFC 1034 and to alter neither +the spirit nor intent of that definition. + +1 Introduction + +The first section of this document will give a crisp overview of what +is begin defined, as well as the motivation for what amounts to a +simple rewording of an original document. An example is included to +help orient the reader. + +Wild card domain names are defined in Section 4.3.3. of RFC 1034 as +"instructions for synthesizing RRs." [RFC1034] The meaning of this is +that a specific, special domain name is used to construct responses in +instances in which the query name is not otherwise represented in a zone. + +A wild card domain name has a specific range of influence on query names +(QNAMEs) within a given class, which is rooted at the domain name +containing the wild card label, and is limited by explicit entries, zone +cuts and empty non-terminal domains (see section 1.3 of this document). + +Note that a wild card domain name has no special impact on the search +for a query type (QTYPE). If a domain name is found that matches the +QNAME (exact or a wild card) but the QTYPE is not found at that point, +the proper response is that there is no data available. The search +does not continue on to seek other wild cards that might match the QTYPE. +To illustrate, a wild card owning an MX RR does not 'cover' other names +in the zone that own an A RR. + +Why is this document needed? Empirical evidence suggests that the +words in RFC 1034 are not clear enough. There exist a number of +implementations that have strayed from the definition. There also +exists a misconception of operators that the wild card can be used to +add a specific RR type to all names, such as the MX RR example listed +above. This document is also needed as input to efforts to extend +DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear +base specification has proven to result in extension documents that +have unpredictable consequences. (This is true in general, not just +for DNS.) + +1.1 Existence + +The notion that a domain name 'exists' will arise numerous times in this +discussion. RFC 1034 raises the issue of existence in a number of places, +usually in reference to non-existence and often in reference to processing +involving wild card domain names. RFC 1034 does contain algorithms that +describe how domain names impact the preparation of an answer and does +define wild cards as a means of synthesizing answers. + +To help clarify the topic of wild cards, a positive definition of existence +is needed. To complicate matters, though, there needs to be a recognition +that existence is relative. To an authoritative server, a domain name +exists if the domain name plays a role following the algorithms of +preparing a response. To a resolver, a domain name exists if there is +any data available corresponding to the name. The difference between the +two is the synthesis of records according to a wild card. + +For the purposes of this document, the point of view of an authoritative +server is adopted. A domain name is said to exist if it plays a role in +the execution of the algorithms in RFC 1034. + +1.2 An Example + +For example, consider this wild card domain name: *.example. Any query +name under example. is a candidate to be matched (answered) by this wild +card. Although any name is a candidate, not all queries will match. + +To further illustrate this, consider this example: + + $ORIGIN example. + @ IN SOA + NS + NS + * TXT "this is a wild card" + MX 10 mailhost.example. + host1 A 10.0.0.1 + _ssh._tcp.host1 SRV + _ssh._tcp.host2 SRV + subdel NS + +The following queries would be synthesized from the wild card: + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host.example. IN MX ..." + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will be a "host.example. IN NXT ..." + because there is no A RR set at '*' + +The following queries would not be synthesized from the wild card: + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN + because host2.example. exists (without data) + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists and is a zone cut + +To the server, the following domains are considered to exist in the zone: +*, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, _ssh._tcp.host2, +and subdel. To a resolver, many more domains appear to exist via the +synthesis of the wild card. + +1.3 Empty Non-terminals + +Empty non-terminals are domain names that have no data but have +subdomains. This is defined in section 3.1 of RFC 1034: + +# The domain name space is a tree structure. Each node and leaf on the +# tree corresponds to a resource set (which may be empty). The domain +# system makes no distinctions between the uses of the interior nodes and +# leaves, and this memo uses the term "node" to refer to both. + +The parenthesized "which may be empty" specifies that empty non-terminals +are explicitly recognized. According to the definition of existence in +this document, empty non-terminals do exist at the server. + +Carefully reading the above paragraph can lead to an interpretation that +all possible domains exist - up to the suggested limit of 255 octets for +a domain name [RFC 1035]. For example, www.example. may have an A RR, and +as far as is practically concerned, is a leaf of the domain tree. But the +definition can be taken to mean that sub.www.example. also exists, albeit +with no data. By extension, all possible domains exist, from the root +down. As RFC 1034 also defines "an authoritative name error indicating +that the name does not exist" in section 4.3.1, this is not the intent +of the original document. + +RFC1034's wording is to be clarified by adding the following paragraph: + + A node is considered to have an impact on the algorithms of 4.3.2 + if it is a leaf node with any resource sets or an interior node, + with or without a resource set, that has a subdomain that is a leaf + node with a resource set. A QNAME and QCLASS matching an existing + node never results in a response return code of authoritative name + error. + +As an aside, an "authoritative name error" has been called NXDOMAIN in +some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned +to such an error by at least one implementation of DNS. + +1.3 Terminology + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this +document are to be interpreted as described in the document entitled +"Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] + +Requirements are denoted by paragraphs that begin with with the following +convention: 'R'.. + +2 Defining the Wild Card Domain Name + +A wild card domain name is defined by having the initial label be: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + +This defines domain names that may play a role in being a wild card, that +is, being a source for synthesized answers. Domain names conforming to +this definition that appear in queries and RDATA sections do not have +any special role. These cases will be described in more detail in +following sections. + +R2.1 A domain name that is to be interpreted as a wild card MUST begin + with a label of '0000 0001 0010 1010' in binary. + +The first octet is the normal label type and length for a 1 octet long +label, the second octet is the ASCII representation [RFC 20] for the +'*' character. In RFC 1034, ASCII encoding is assumed to be the character +encoding. + +In the master file formats used in RFCs, a "*" is a legal representation +for the wild card label. Even if the "*" is escaped, it is still +interpreted as the wild card when it is the only character in the label. + +R2.2. A server MUST treat a wild card domain name as the basis of + synthesized answers regardless of any "escape" sequences in + the input format. + +RFC 1034 and RFC 1035 ignore the case in which a domain name might be +"the*.example.com." The interpretation is that this domain name in a +zone would only match queries for "the*.example.com" and not have any +other role. + +Note: By virtue of this definition, a wild card domain name may have a +subdomain. The subdomain (or sub-subdomain) itself may also be a wild +card. E.g., *.*.example. is a wild card, so is *.sub.*.example. +More discussion on this is given in Appendix A. + +3 Defining Existence + +As described in the Introduction, a precise definition of existence is +needed. + +R3.1 An authoritative server MUST treat a domain name as existing during + the execution of the algorithms in RFC 1034 when the domain name + conforms to the following definition. A domain name is defined + to exist if the domain name owns data and/or has a subdomain that + exists. + +Note that at a zone boundary, the domain name owns data, including the +NS RR set. At the delegating server, the NS RR set is not authoritative, +but that is of no consequence here. The domain name owns data, therefore, +it exists. + +R3.2 An authoritative server MUST treat a domain name that has neither + a resource record set nor a subdomain as nonexistent when executing + the algorithm in section 4.3.2. of RFC 1034. + +4 Impact of a Wild Card Domain In a Query Message + +When a wild card domain name appears in a question, e.g., the query name +is "*.example.", the response in no way differs from any other query. +In other words, the wild card label in a QNAME has no special meaning, +and query processing will proceed using '*' as a literal query name. + +R4.1 A wild card domain name acting as a QNAME MUST be treated as any + other QNAME, there MUST be no special processing accorded it. + +If a wild card domain name appears in the RDATA of a CNAME RR or any +other RR that has a domain name in it, the same rule applies. In the +instance of a CNAME RR, the wild card domain name is used in the same +manner of as being the original QNAME. For other RR's, rules vary +regarding what is done with the domain name(s) appearing in them, +in no case does the wild card hold special meaning. + +R4.2 A wild card domain name appearing in any RR's RDATA MUST be treated + as any other domain name in that situation, there MUST be no special + processing accorded it. + +5 Impact of a Wild Card Domain On a Response + +The description of how wild cards impact response generation is in RFC +1034, section 4.3.2. That passage contains the algorithm followed by a +server in constructing a response. Within that algorithm step 3, part +'c' defines the behavior of the wild card. The algorithm is directly +quoted in lines that begin with a '#' sign. Commentary is interleaved. + +[Note that are no requirements specifically listed in this section. The +text here is explanatory and interpretative. There is no change to +the algorithm specified in RFC 1034.] + +The context of part 'c' is that the search is progressing label by label +through the QNAME. (Note that the data being searched is the authoritative +data in the server, the cache is searched in step 4.) Step 3's part 'a' +covers the case that the QNAME has been matched in full, regardless of the +presence of a CNAME RR. Step 'b' covers crossing a cut point, resulting +in a referral. All that is left is to look for the wild card. + +Step 3 of the algorithm also assumes that the search is looking in the +zone closest to the answer, i.e., in the same class as QCLASS and as +close to the authority as possible on this server. If the zone is not +the authority, then a referral is given, possibly one indicating lameness. + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if a +# the "*" label exists. + +The above paragraph refers to finding the domain name that exists in the +zone and that most encloses the QNAME. Such a domain name will mark the +boundary of candidate wild card domain names that might be used to +synthesize an answer. (Remember that at this point, if the most enclosing +name is the same as the QNAME, part 'a' would have recorded an exact +match.) The existence of the enclosing name means that no wild card name +higher in the tree is a candidate to answer the query. + +Once the closest enclosing node is identified, there's the matter of what +exists below it. It may have subdomains, but none will be closer to the +QNAME. One of the subdomains just might be a wild card. If it exists, +this is the only wild card eligible to be used to synthesize an answer +for the query. Even if the closest enclosing node conforms to the syntax +rule in section 2 for being a wild card domain name, the closest enclosing +node is not eligible to be a source of a synthesized answer. + +The only wild card domain name that is a candidate to synthesize an answer +will be the "*" subdomain of the closest enclosing domain name. Three +possibilities can happen. The "*" subdomain does not exist, the "*" +subdomain does but does not have an RR set of the same type as the QTYPE, +or it exists and has the desired RR set. + +For the sake of brevity, the closest enclosing node can be referred to as +the "closest encloser." + +To illustrate, using the example in section 1.2 of this document, the +following chart shows QNAMEs and the closest enclosers. In Appendix A +there is another chart showing unusual cases. + + QNAME Closest Encloser Wild Card Source + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no wild card + _telnet._tcp.host2.example. host2.example. no wild card + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + +Note that host1.subdel.example. is in a subzone, so the search for it ends +in a referral in part 'b', thus does not enter into finding a closest +encloser. + +The fact that a closest encloser will be the only superdomain that +can have a candidate wild card will have an impact when it comes to +designing authenticated denial of existence proofs. (This concept +is not introduced until DNS Security Extensions are considered in +upcoming sections.) + +# If the "*" label does not exist, check whether the name +# we are looking for is the original QNAME in the query +# or a name we have followed due to a CNAME. If the name +# is original, set an authoritative name error in the +# response and exit. Otherwise just exit. + +The above passage says that if there is not even a wild card domain name +to match at this point (failing to find an explicit answer elsewhere), +we are to return an authoritative name error at this point. If we were +following a CNAME, the specification is unclear, but seems to imply that +a no error return code is appropriate, with just the CNAME RR (or sequence +of CNAME RRs) in the answer section. + +# If the "*" label does exist, match RRs at that node +# against QTYPE. If any match, copy them into the answer +# section, but set the owner of the RR to be QNAME, and +# not the node with the "*" label. Go to step 6. + +This final paragraph covers the role of the QTYPE in the process. Note +that if no resource record set matches the QTYPE the result is that no data +is copied, but the search still ceases ("Go to step 6."). + +6 Authenticated Denial and Wild Cards + +In unsecured DNS, the only concern when there is no data to return to +a query is whether the domain name from which the answer comes exists or +not, whether or not a name error is indicated in the return code. In +either case the answer section is empty or contained just a sequence of +CNAME RR sets. + +In securing DNS, authenticated denial of existence is a service that is +provided. The chosen solution to provide this service is to generate +resource records indicating what is protected in a zone and to digitally +sign these. + +The resource records that do this, as defined in RFC 2535, are NXT RRs. + +There are three points to consider when clarifying the topic of wild card +domain names. One is the construction of the records. The second is +the inclusion of records in responses. The third is the interpretation +of the records in a response by the resolver. + +6.1 Preparing Wild Card Domain Name Owned Non-existence Proofs + +During the creation of the authenticated denial records, the wild card +domain name plays no special role, in the same manner as the wild card +domain name playing no special role in a query. + +There is one consideration with regards to preparing non-existence +proofs. + +R6.1 Any mechanism used to provide authenticated denial MUST reveal the + closest enclosing existing domain for the query. If this is not + provided, the resolver will not be able to ascertain the identity + of an appropriate wild card domain name. + +6.2 Role of Wild Cards in Answers + +There are three cases to address. The first is synthesizing from wild card +domain name with data, the second is negatively synthesizing from an +existing wild card, and the third is denying that neither an exact match, +referral, nor wild card exist to answer the query. + +6.2.1 Synthesizing From a Wild Card + +When preparing an answer from a wild card domain name, the answer needs +to include proof that the exact match of the QNAME and QCLASS does not +exist. This is needed because synthesis of the answer replaces the "*" +label with the QNAME without securing the result. The resolver will +realize that the answer was derived from a wild card, but cannot +detect whether an exact match was maliciously omitted. + +R6.2 When synthesizing a positive answer from a wild card domain name, the + answer MUST include proof that the exact match for the QNAME and + QCLASS does not exist. + +6.2.2. Synthesizing Negatively From a Wild Card + +When synthesizing a negative answer that is derived from a wild card, +meaning that a wild card matched the QNAME (no exact match happened for +QNAME) but that there is no match for QTYPE there, two negative answers +are needed, possibly one. As in 6.2.1, a proof that the exact match +failed is needed. A second proof is needed to show that the wild card +domain name does not have the QTYPE. Depending on the method of +authenticated denial, these this could be possible with one statement. + +R6.3 When synthesizing a negative answer from a wild card domain name, + the answer MUST include proof that the exact match of the QNAME + and QCLASS does not exist and that the QTYPE matches no RR set at + the wild card. If this answer can be optimized, an implementation + SHOULD reduce the number of records included in the response. + +6.2.3. Answering With an Authoritative Name Error + +When answering with a result code of a name error, the answer needs to +provide proof that neither the exact match for QNAME and QCLASS exists +nor that a wild card domain name exists as a subdomain of the closest +enclosing domain name. + +R6.4 When preparing a reply with an authoritative name error, the answer + MUST include proof that the exact match for the QNAME and QCLASS + does not exist and that no wild card is available to provide a match. + +6.2.4. The Remaining Case + +When answering negatively because there is a match for QNAME and QCLASS +but no match for the QTYPE, only a proof for that is needed. Just as +the search does not proceed onto a search for the wild card in this +case, neither does the construction of the negative answer proof. + +R6.5 When preparing a reply in which there is an exact match of the + QNAME and QCLASS, but there is no RR set matching the QTYPE, + the reply SHOULD NOT contain any proof regarding the wild card + domain name. + +6.3 Interpreting Negative Answers Involving Wild Cards + +There are two requirements for resolvers when it comes to handling +negative answers generated as described in section 6.2. + +R6.6 A resolver MUST be able to identify negative answer data that + indicate when a match for QNAME and QCLASS does not exist. + +R6.7 From a negative answer, a resolver MUST be able to determine + the closest enclosing domain name in a negative answer and + MUST be able to process a negative answer involving the one + wild card domain name that is a candidate to provide a + synthesized answer. + +6.4 Authenticated Denial, Wild Card Domain Names, and Opt-In + +When considering the Opt-In proposal [WIP], it is wise to not combine +a zone that adheres to both opt-in and that has a wild card domain +name. The reason is rooted in that the synthesis of an answer is done +by substituting the QNAME for the wild card domain name in the answer. +Because this is unsecured, and the is ambiguity regarding whether a +negative proof can be provided for the exact match (when it is outside +the opt-in secured area), a definitive proof of authenticated denial +is not possible. + +7 Security Considerations + +This document is refining the specifications to make it more likely that +security can be added to DNS. No functional additions are being made, +just refining what is considered proper to allow the system, security +of the system, and extending the system more predictable. + +8 References + +Normative References + +[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 +[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, + Nov-01-1987 +[RFC 1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 +[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S + Bradner, March 1997 + +Non-normative References + +[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, + Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 +[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 +[WIP] DNSSEC Opt-In, Internet Draft, R. Arends, M. Kosters, D. Blacka, 2002 + +9 Other Contributing to This Document + +Others who have directly caused text to appear in the document: Paul Vixie +and Olaf Kolkman. Many others have indirect influences on the content. + +10 Editor + +Name: Edward Lewis +Title: Research Engineer +Affiliation: ARIN +Email: edlewis@arin.net +Phone: +1-703-227-9854 + +Appendix A: Subdomains of Wild Card Domain Names + +In reading the definition of section 2 carefully, it is possible to +rationalize unusual names as legal. In the example given, *.example. +could have subdomains of *.sub.*.example. and even the more direct +*.*.example. (The implication here is that these domain names own +explicit resource records sets.) Although defining these names is not +easy to justify, it is important that implementations account for the +possibility. This section will give some further guidance on handling +these names. + +The first thing to realize is that by all definitions, subdomains of +wild card domain names are legal. In analyzing them, one realizes +that they cause no harm by their existence. Because of this, they are +allowed to exist, i.e., there are no special case rules made to disallow +them. The reason for not preventing these names is that the prevention +would just introduce more code paths to put into implementations. + +The concept of "closest enclosing" existing names is important to keep in +mind. It is also important to realize that a wild card domain name can +be a closest encloser of a query name. For example, if *.*.example. is +defined in a zone, and the query name is a.*.example., then the closest +enclosing domain name is *.example. Keep in mind that the closest +encloser is not eligible to be a source of synthesized answers, just the +subdomain of it that has the first label "*". + +To illustrate this, the following chart shows some matches. Assume that +the names *.example., *.*.example., and *.sub.*.example. are defined +in the zone. + + QNAME Closest Encloser Wild Card Source + a.example. example. *.example. + b.a.example. example. *.example. + a.*.example. *.example. *.*.example. + b.a.*.example. *.example. *.*.example. + b.a.*.*.example. *.*.example. no wild card + a.sub.*.example. sub.*.example. *.sub.*.example. + b.a.sub.*.example. sub.*.example. *.sub.*.example. + a.*.sub.*.example. *.sub.*.example. no wild card + *.a.example. example. *.example. + a.sub.b.example. example. *.example. + +Recall that the closest encloser itself cannot be the wild card. Therefore +the match for b.a.*.*.example. has no applicable wild card. + +Finally, if a query name is sub.*.example., any answer available will come +from an exact name match for sub.*.example. No wild card synthesis is +performed in this case. + +Full Copyright Statement + + Copyright (C) The Internet Society 2003. All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights defined + in the Internet Standards process must be followed, or as required to + translate it into languages other than English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT + NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN + WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + +-- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +Edward Lewis +1-703-227-9854 +ARIN Research Engineer +