diff options
Diffstat (limited to 'doc/rfc/rfc4592.txt')
| -rw-r--r-- | doc/rfc/rfc4592.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc4592.txt b/doc/rfc/rfc4592.txt new file mode 100644 index 0000000..cc4eb75 --- /dev/null +++ b/doc/rfc/rfc4592.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group E. Lewis +Request for Comments: 4592 NeuStar +Updates: 1034, 2672 July 2006 +Category: Standards Track + + + The Role of Wildcards + in the Domain Name System + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This is an update to the wildcard definition of RFC 1034. The + interaction with wildcards and CNAME is changed, an error condition + is removed, and the words defining some concepts central to wildcards + are changed. The overall goal is not to change wildcards, but to + refine the definition of RFC 1034. + + + + + + + + + + + + + + + + + + + + + + + +Lewis Standards Track [Page 1] + +RFC 4592 DNSEXT WCARD July 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Motivation .................................................3 + 1.2. The Original Definition ....................................3 + 1.3. Roadmap to This Document ...................................4 + 1.3.1. New Terms ...........................................5 + 1.3.2. Changed Text ........................................5 + 1.3.3. Considerations with Special Types ...................5 + 1.4. Standards Terminology ......................................6 + 2. Wildcard Syntax .................................................6 + 2.1. Identifying a Wildcard .....................................6 + 2.1.1. Wildcard Domain Name and Asterisk Label .............6 + 2.1.2. Asterisks and Other Characters ......................7 + 2.1.3. Non-terminal Wildcard Domain Names ..................7 + 2.2. Existence Rules ............................................7 + 2.2.1. An Example ..........................................8 + 2.2.2. Empty Non-terminals .................................9 + 2.2.3. Yet Another Definition of Existence ................10 + 2.3. When Is a Wildcard Domain Name Not Special? ...............10 + 3. Impact of a Wildcard Domain Name on a Response .................10 + 3.1. Step 2 ....................................................11 + 3.2. Step 3 ....................................................11 + 3.3. Part 'c' ..................................................12 + 3.3.1. Closest Encloser and the Source of Synthesis .......12 + 3.3.2. Closest Encloser and Source of Synthesis Examples ..13 + 3.3.3. Type Matching ......................................13 + 4. Considerations with Special Types ..............................14 + 4.1. SOA RRSet at a Wildcard Domain Name .......................14 + 4.2. NS RRSet at a Wildcard Domain Name ........................14 + 4.2.1. Discarded Notions ..................................15 + 4.3. CNAME RRSet at a Wildcard Domain Name .....................16 + 4.4. DNAME RRSet at a Wildcard Domain Name .....................16 + 4.5. SRV RRSet at a Wildcard Domain Name .......................17 + 4.6. DS RRSet at a Wildcard Domain Name ........................17 + 4.7. NSEC RRSet at a Wildcard Domain Name ......................18 + 4.8. RRSIG at a Wildcard Domain Name ...........................18 + 4.9. Empty Non-terminal Wildcard Domain Name ...................18 + 5. Security Considerations ........................................18 + 6. References .....................................................18 + 6.1. Normative References ......................................18 + 6.2. Informative References ....................................19 + 7. Others Contributing to the Document ............................19 + + + + + + + + +Lewis Standards Track [Page 2] + +RFC 4592 DNSEXT WCARD July 2006 + + +1. Introduction + + In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the + synthesis of answers from special resource records (RRs) called + wildcards. The definition in RFC 1034 is incomplete and has proven + to be confusing. This document describes the wildcard synthesis by + adding to the discussion and making limited modifications. + Modifications are made to close inconsistencies that have led to + interoperability issues. This description does not expand the + service intended by the original definition. + + Staying within the spirit and style of the original documents, this + document avoids specifying rules for DNS implementations regarding + wildcards. The intention is to only describe what is needed for + interoperability, not restrict implementation choices. In addition, + consideration is given to minimize any backward-compatibility issues + with implementations that comply with RFC 1034's definition. + + This document is focused on the concept of wildcards as defined in + RFC 1034. Nothing is implied regarding alternative means of + synthesizing resource record sets (RRSets), nor are alternatives + discussed. + +1.1. Motivation + + Many DNS implementations diverge, in different ways, from the + original definition of wildcards. Although there is clearly a need + to clarify the original documents in light of this alone, the impetus + for this document lay in the engineering of the DNS security + extensions [RFC4033]. With an unclear definition of wildcards, the + design of authenticated denial became entangled. + + This document is intended to limit its changes, documenting only + those deemed necessary based on implementation experience, and to + remain as close to the original document as possible. To reinforce + that this document is meant to clarify and adjust and not redefine + wildcards, relevant sections of RFC 1034 are repeated verbatim to + facilitate comparison of the old and new text. + +1.2. The Original Definition + + The definition of the wildcard concept is comprised by the + documentation of the algorithm by which a name server prepares a + response (in RFC 1034's section 4.3.2) and the way in which a + resource record (set) is identified as being a source of synthetic + data (section 4.3.3). + + + + + +Lewis Standards Track [Page 3] + +RFC 4592 DNSEXT WCARD July 2006 + + + This is the definition of the term "wildcard" as it appears in RFC + 1034, section 4.3.3. + + # In the previous algorithm, special treatment was given to RRs with + # owner names starting with the label "*". Such RRs are called + # wildcards. Wildcard RRs can be thought of as instructions for + # synthesizing RRs. When the appropriate conditions are met, the + # name server creates RRs with an owner name equal to the query name + # and contents taken from the wildcard RRs. + + This passage follows the algorithm in which the term wildcard is + first used. In this definition, wildcard refers to resource records. + In other usage, wildcard has referred to domain names, and it has + been used to describe the operational practice of relying on + wildcards to generate answers. It is clear from this that there is a + need to define clear and unambiguous terminology in the process of + discussing wildcards. + + The mention of the use of wildcards in the preparation of a response + is contained in step 3, part 'c' of RFC 1034's section 4.3.2, + entitled "Algorithm". Note that "wildcard" does not appear in the + algorithm, instead references are made to the "*" label. The portion + of the algorithm relating to wildcards is deconstructed in detail in + section 3 of this document; this is the beginning of the relevant + portion of the "Algorithm". + + # c. If at some label, a match is impossible (i.e., the + # corresponding label does not exist), look to see if [...] + # the "*" label exists. + + The scope of this document is the RFC 1034 definition of wildcards + and the implications of updates to those documents, such as DNS + Security (DNSSEC). Alternate schemes for synthesizing answers are + not considered. (Note that there is no reference listed. No + document is known to describe any alternate schemes, although there + has been some mention of them in mailing lists.) + +1.3. Roadmap to This Document + + This document accomplishes these three tasks. + + o Defines new terms + + o Makes minor changes to avoid conflicting concepts + + o Describes the actions of certain resource records as wildcards + + + + + +Lewis Standards Track [Page 4] + +RFC 4592 DNSEXT WCARD July 2006 + + +1.3.1. New Terms + + To help in discussing what resource records are wildcards, two terms + will be defined: "asterisk label" and "wildcard domain name". These + are defined in section 2.1.1. + + To assist in clarifying the role of wildcards in the name server + algorithm in RFC 1034, section 4.3.2, "source of synthesis" and + "closest encloser" are defined. These definitions are in section + 3.3.1. "Label match" is defined in section 3.2. + + The new terms are used to make discussions of wildcards clearer. + Terminology does not directly have an impact on implementations. + +1.3.2. Changed Text + + The definition of "existence" is changed superficially. This change + will not be apparent to implementations; it is needed to make + descriptions more precise. The change appears in section 2.2.3. + + RFC 1034, section 4.3.3, seems to prohibit having two asterisk labels + in a wildcard owner name. With this document, the restriction is + removed entirely. This change and its implications are in section + 2.1.3. + + The actions when a source of synthesis owns a CNAME RR are changed to + mirror the actions if an exact match name owns a CNAME RR. This is + an addition to the words in RFC 1034, section 4.3.2, step 3, part + 'c'. The discussion of this is in section 3.3.3. + + Only the latter change represents an impact to implementations. The + definition of existence is not a protocol impact. The change to the + restriction on names is unlikely to have an impact, as RFC 1034 + contained no specification on when and how to enforce the + restriction. + +1.3.3. Considerations with Special Types + + This document describes semantics of wildcard RRSets for + "interesting" types as well as empty non-terminal wildcards. + Understanding these situations in the context of wildcards has been + clouded because these types incur special processing if they are the + result of an exact match. This discussion is in section 4. + + These discussions do not have an implementation impact; they cover + existing knowledge of the types, but to a greater level of detail. + + + + + +Lewis Standards Track [Page 5] + +RFC 4592 DNSEXT WCARD July 2006 + + +1.4. Standards Terminology + + This document does not use terms as defined in "Key words for use in + RFCs to Indicate Requirement Levels" [RFC2119]. + + Quotations of RFC 1034 are denoted by a '#' at the start of the line. + References to section "4.3.2" are assumed to refer to RFC 1034's + section 4.3.2, simply titled "Algorithm". + +2. Wildcard Syntax + + The syntax of a wildcard is the same as any other DNS resource + record, across all classes and types. The only significant feature + is the owner name. + + Because wildcards are encoded as resource records with special names, + they are included in zone transfers and incremental zone transfers + [RFC1995] just as non-wildcard resource records are. This feature + has been under appreciated until discussions on alternative + approaches to wildcards appeared on mailing lists. + +2.1. Identifying a Wildcard + + To provide a more accurate description of wildcards, the definition + has to start with a discussion of the domain names that appear as + owners. Two new terms are needed, "asterisk label" and "wildcard + domain name". + +2.1.1. Wildcard Domain Name and Asterisk Label + + A "wildcard domain name" is defined by having its initial (i.e., + leftmost or least significant) label be, in binary format: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + + The first octet is the normal label type and length for a 1-octet- + long label, and the second octet is the ASCII representation [RFC20] + for the '*' character. + + A descriptive name of a label equaling that value is an "asterisk + label". + + RFC 1034's definition of wildcard would be "a resource record owned + by a wildcard domain name". + + + + + + + +Lewis Standards Track [Page 6] + +RFC 4592 DNSEXT WCARD July 2006 + + +2.1.2. Asterisks and Other Characters + + No label values other than that in section 2.1.1 are asterisk labels, + hence names beginning with other labels are never wildcard domain + names. Labels such as 'the*' and '**' are not asterisk labels, so + these labels do not start wildcard domain names. + +2.1.3. Non-terminal Wildcard Domain Names + + In section 4.3.3, the following is stated: + + # .......................... The owner name of the wildcard RRs is + # of the form "*.<anydomain>", where <anydomain> is any domain name. + # <anydomain> should not contain other * labels...................... + + The restriction is now removed. The original documentation of it is + incomplete and the restriction does not serve any purpose given years + of operational experience. + + There are three possible reasons for putting the restriction in + place, but none of the three has held up over time. One is that the + restriction meant that there would never be subdomains of wildcard + domain names, but the restriction as stated still permits + "example.*.example." for instance. Another is that wildcard domain + names are not intended to be empty non-terminals, but this situation + does not disrupt the algorithm in 4.3.2. Finally, "nested" wildcard + domain names are not ambiguous once the concept of the closest + encloser had been documented. + + A wildcard domain name can have subdomains. There is no need to + inspect the subdomains to see if there is another asterisk label in + any subdomain. + + A wildcard domain name can be an empty non-terminal. (See the + upcoming sections on empty non-terminals.) In this case, any lookup + encountering it will terminate as would any empty non-terminal match. + +2.2. Existence Rules + + The notion that a domain name 'exists' is mentioned in the definition + of wildcards. In section 4.3.3 of RFC 1034: + + # Wildcard RRs do not apply: + # + ... + # - When the query name or a name between the wildcard domain and + # the query name is know[n] to exist. . . . + + + + +Lewis Standards Track [Page 7] + +RFC 4592 DNSEXT WCARD July 2006 + + + "Existence" is therefore an important concept in the understanding of + wildcards. Unfortunately, the definition of what exists, in RFC + 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is + taken at the definition of existence. + +2.2.1. An Example + + To illustrate what is meant by existence consider this complete zone: + + $ORIGIN example. + example. 3600 IN SOA <SOA RDATA> + example. 3600 NS ns.example.com. + example. 3600 NS ns.example.net. + *.example. 3600 TXT "this is a wildcard" + *.example. 3600 MX 10 host1.example. + sub.*.example. 3600 TXT "this is not a wildcard" + host1.example. 3600 A 192.0.2.1 + _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> + _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> + subdel.example. 3600 NS ns.example.com. + subdel.example. 3600 NS ns.example.net. + + A look at the domain names in a tree structure is helpful: + + | + -------------example------------ + / / \ \ + / / \ \ + / / \ \ + * host1 host2 subdel + | | | + | | | + sub _tcp _tcp + | | + | | + _ssh _ssh + + The following responses would be synthesized from one of the + wildcards in the zone: + + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host3.example. IN MX ..." + + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will reflect "no error, but no data" + because there is no A RR set at '*.example.' + + + + + +Lewis Standards Track [Page 8] + +RFC 4592 DNSEXT WCARD July 2006 + + + QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN + the answer will be "foo.bar.example. IN TXT ..." + because bar.example. does not exist, but the wildcard + does. + + The following responses would not be synthesized from any of the + wildcards in the zone: + + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + + QNAME=sub.*.example., QTYPE=MX, QCLASS=IN + because sub.*.example. exists + + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists (and is a zone cut) + + QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN + because *.example. exists + + The final example highlights one common misconception about + wildcards. A wildcard "blocks itself" in the sense that a wildcard + does not match its own subdomains. That is, "*.example." does not + match all names in the "example." zone; it fails to match the names + below "*.example.". To cover names under "*.example.", another + wildcard domain name is needed--"*.*.example."--which covers all but + its own subdomains. + +2.2.2. Empty Non-terminals + + Empty non-terminals [RFC2136, section 7.16] are domain names that own + no resource records but have subdomains that do. In section 2.2.1, + "_tcp.host1.example." is an example of an empty non-terminal name. + Empty non-terminals are introduced by this text 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 and that empty non-terminals + "exist". + + + +Lewis Standards Track [Page 9] + +RFC 4592 DNSEXT WCARD July 2006 + + + Pedantically 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 [RFC1035]. 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 on down. + + As RFC 1034 also defines "an authoritative name error indicating that + the name does not exist" in section 4.3.1, so this apparently is not + the intent of the original definition, justifying the need for an + updated definition in the next section. + +2.2.3. Yet Another Definition of Existence + + RFC 1034's wording is fixed by the following paragraph: + + The domain name space is a tree structure. Nodes in the tree either + own at least one RRSet and/or have descendants that collectively own + at least one RRSet. A node may exist with no RRSets only if it has + descendants that do; this node is an empty non-terminal. + + A node with no descendants is a leaf node. Empty leaf nodes do not + exist. + + Note that at a zone boundary, the domain name owns data, including + the NS RR set. In the delegating zone, the NS RR set is not + authoritative, but that is of no consequence here. The domain name + owns data; therefore, it exists. + +2.3. When Is a Wildcard Domain Name Not Special? + + When a wildcard domain name appears in a message's query section, no + special processing occurs. An asterisk label in a query name only + matches a single, corresponding asterisk label in the existing zone + tree when the 4.3.2 algorithm is being followed. + + When a wildcard domain name appears in the resource data of a record, + no special processing occurs. An asterisk label in that context + literally means just an asterisk. + +3. Impact of a Wildcard Domain Name on a Response + + RFC 1034's description of how wildcards impact response generation is + in its 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 wildcard. + + + + +Lewis Standards Track [Page 10] + +RFC 4592 DNSEXT WCARD July 2006 + + + The algorithm in section 4.3.2 is not intended to be pseudo-code; + that is, its steps are not intended to be followed in strict order. + The "algorithm" is a suggested means of implementing the + requirements. As such, in step 3, parts 'a', 'b', and 'c' do not + have to be implemented in that order, provided that the result of the + implemented code is compliant with the protocol's specification. + +3.1. Step 2 + + Step 2 of section 4.3.2 reads: + + # 2. Search the available zones for the zone which is the nearest + # ancestor to QNAME. If such a zone is found, go to step 3, + # otherwise step 4. + + In this step, the most appropriate zone for the response is chosen. + The significance of this step is that it means all of step 3 is being + performed within one zone. This has significance when considering + whether or not an SOA RR can ever be used for synthesis. + +3.2. Step 3 + + Step 3 is dominated by three parts, labeled 'a', 'b', and 'c'. But + the beginning of the step is important and needs explanation. + + # 3. Start matching down, label by label, in the zone. The + # matching process can terminate several ways: + + The word 'matching' refers to label matching. The concept is based + in the view of the zone as the tree of existing names. The query + name is considered to be an ordered sequence of labels--as if the + name were a path from the root to the owner of the desired data + (which it is--3rd paragraph of RFC 1034, section 3.1). + + The process of label matching a query name ends in exactly one of + three choices, the parts 'a', 'b', and 'c'. Either the name is + found, the name is below a cut point, or the name is not found. + + Once one of the parts is chosen, the other parts are not considered + (e.g., do not execute part 'c' and then change the execution path to + finish in part 'b'). The process of label matching is also done + independent of the query type (QTYPE). + + Parts 'a' and 'b' are not an issue for this clarification as they do + not relate to record synthesis. Part 'a' is an exact match that + results in an answer; part 'b' is a referral. + + + + + +Lewis Standards Track [Page 11] + +RFC 4592 DNSEXT WCARD July 2006 + + +3.3. Part 'c' + + The context of part 'c' is that the process of label matching the + labels of the query name has resulted in a situation in which there + is no corresponding label in the tree. It is as if the lookup has + "fallen off the tree". + + # c. If at some label, a match is impossible (i.e., the + # corresponding label does not exist), look to see if [...] + # the "*" label exists. + + To help describe the process of looking 'to see if [...] the "*" + label exists' a term has been coined to describe the last domain + (node) matched. The term is "closest encloser". + +3.3.1. Closest Encloser and the Source of Synthesis + + The closest encloser is the node in the zone's tree of existing + domain names that has the most labels matching the query name + (consecutively, counting from the root label downward). Each match + is a "label match" and the order of the labels is the same. + + The closest encloser is, by definition, an existing name in the zone. + The closest encloser might be an empty non-terminal or even be a + wildcard domain name itself. In no circumstances is the closest + encloser to be used to synthesize records for the current query. + + The source of synthesis is defined in the context of a query process + as that wildcard domain name immediately descending from the closest + encloser, provided that this wildcard domain name exists. + "Immediately descending" means that the source of synthesis has a + name of the form: + + <asterisk label>.<closest encloser>. + + A source of synthesis does not guarantee having a RRSet to use for + synthesis. The source of synthesis could be an empty non-terminal. + + If the source of synthesis does not exist (not on the domain tree), + there will be no wildcard synthesis. There is no search for an + alternate. + + The important concept is that for any given lookup process, there is + at most one place at which wildcard synthetic records can be + obtained. If the source of synthesis does not exist, the lookup + terminates, and the lookup does not look for other wildcard records. + + + + + +Lewis Standards Track [Page 12] + +RFC 4592 DNSEXT WCARD July 2006 + + +3.3.2. Closest Encloser and Source of Synthesis Examples + + To illustrate, using the example zone in section 2.2.1 of this + document, the following chart shows QNAMEs and the closest enclosers. + + QNAME Closest Encloser Source of Synthesis + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no source + _dns._udp.host2.example. host2.example. no source + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + foobar.*.example. *.example. no source + +3.3.3. Type Matching + + RFC 1034 concludes part 'c' with this: + + # 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. + # + # 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. + + The final paragraph covers the role of the QTYPE in the lookup + process. + + Based on implementation feedback and similarities between part 'a' + and part 'c', a change to this passage has been made. + + The change is to add the following text to part 'c' prior to the + instructions to "go to step 6": + + If the data at the source of synthesis is a CNAME, and QTYPE + doesn't match CNAME, copy the CNAME RR into the answer section of + the response changing the owner name to the QNAME, change QNAME to + the canonical name in the CNAME RR, and go back to step 1. + + This is essentially the same text in part 'a' covering the processing + of CNAME RRSets. + + + + + + + +Lewis Standards Track [Page 13] + +RFC 4592 DNSEXT WCARD July 2006 + + +4. Considerations with Special Types + + Sections 2 and 3 of this document discuss wildcard synthesis with + respect to names in the domain tree and ignore the impact of types. + In this section, the implication of wildcards of specific types is + discussed. The types covered are those that have proven to be the + most difficult to understand. The types are SOA, NS, CNAME, DNAME, + SRV, DS, NSEC, RRSIG, and "none", that is, empty non-terminal + wildcard domain names. + +4.1. SOA RRSet at a Wildcard Domain Name + + A wildcard domain name owning an SOA RRSet means that the domain is + at the root of the zone (apex). The domain cannot be a source of + synthesis because that is, by definition, a descendant node (of the + closest encloser) and a zone apex is at the top of the zone. + + Although a wildcard domain name owning an SOA RRSet can never be a + source of synthesis, there is no reason to forbid the ownership of an + SOA RRSet. + + For example, given this zone: + + $ORIGIN *.example. + @ 3600 IN SOA <SOA RDATA> + 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + www 3600 TXT "the www txt record" + + A query for www.*.example.'s TXT record would still find the "the www + txt record" answer. The asterisk label only becomes significant when + section 4.3.2, step 3, part 'c' is in effect. + + Of course, there would need to be a delegation in the parent zone, + "example." for this to work too. This is covered in the next + section. + +4.2. NS RRSet at a Wildcard Domain Name + + With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now in + place, the semantics of a wildcard domain name owning an NS RRSet has + come to be poorly defined. The dilemma relates to a conflict between + the rules for synthesis in part 'c' and the fact that the resulting + synthesis generates a record for which the zone is not authoritative. + In a DNSSEC signed zone, the mechanics of signature management + (generation and inclusion in a message) have become unclear. + + + + + +Lewis Standards Track [Page 14] + +RFC 4592 DNSEXT WCARD July 2006 + + + Salient points of the working group discussion on this topic are + summarized in section 4.2.1. + + As a result of these discussions, there is no definition given for + wildcard domain names owning an NS RRSet. The semantics are left + undefined until there is a clear need to have a set defined, and + until there is a clear direction to proceed. Operationally, + inclusion of wildcard NS RRSets in a zone is discouraged, but not + barred. + +4.2.1. Discarded Notions + + Prior to DNSSEC, a wildcard domain name owning a NS RRSet appeared to + be workable, and there are some instances in which it is found in + deployments using implementations that support this. Continuing to + allow this in the specification is not tenable with DNSSEC. The + reason is that the synthesis of the NS RRSet is being done in a zone + that has delegated away the responsibility for the name. This + "unauthorized" synthesis is not a problem for the base DNS protocol, + but DNSSEC in affirming the authorization model for DNS exposes the + problem. + + Outright banning of wildcards of type NS is also untenable as the DNS + protocol does not define how to handle "illegal" data. + Implementations may choose not to load a zone, but there is no + protocol definition. The lack of the definition is complicated by + having to cover dynamic update [RFC2136] and zone transfers, as well + as loading at the master server. The case of a client (resolver, + caching server) getting a wildcard of type NS in a reply would also + have to be considered. + + Given the daunting challenge of a complete definition of how to ban + such records, dealing with existing implementations that permit the + records today is a further complication. There are uses of wildcard + domain name owning NS RRSets. + + One compromise proposed would have redefined wildcards of type NS to + not be used in synthesis, this compromise fell apart because it would + have required significant edits to the DNSSEC signing and validation + work. (Again, DNSSEC catches unauthorized data.) + + With no clear consensus forming on the solution to this dilemma, and + the realization that wildcards of type NS are a rarity in operations, + the best course of action is to leave this open-ended until "it + matters". + + + + + + +Lewis Standards Track [Page 15] + +RFC 4592 DNSEXT WCARD July 2006 + + +4.3. CNAME RRSet at a Wildcard Domain Name + + The issue of a CNAME RRSet owned by a wildcard domain name has + prompted a suggested change to the last paragraph of step 3c of the + algorithm in 4.3.2. The changed text appears in section 3.3.3 of + this document. + +4.4. DNAME RRSet at a Wildcard Domain Name + + Ownership of a DNAME [RFC2672] RRSet by a wildcard domain name + represents a threat to the coherency of the DNS and is to be avoided + or outright rejected. Such a DNAME RRSet represents non- + deterministic synthesis of rules fed to different caches. As caches + are fed the different rules (in an unpredictable manner) the caches + will cease to be coherent. ("As caches are fed" refers to the + storage in a cache of records obtained in responses by recursive or + iterative servers.) + + For example, assume one cache, responding to a recursive request, + obtains the following record: + + "a.b.example. DNAME foo.bar.example.net." + + and another cache obtains: + + "b.example. DNAME foo.bar.example.net." + + both generated from the record: + + "*.example. DNAME foo.bar.example.net." + + by an authoritative server. + + The DNAME specification is not clear on whether DNAME records in a + cache are used to rewrite queries. In some interpretations, the + rewrite occurs; in others, it does not. Allowing for the occurrence + of rewriting, queries for "sub.a.b.example. A" may be rewritten as + "sub.foo.bar.tld. A" by the former caching server and may be + rewritten as "sub.a.foo.bar.tld. A" by the latter. Coherency is + lost, and an operational nightmare ensues. + + Another justification for a recommendation to avoid the use of + wildcard DNAME records is the observation that such a record could + synthesize a DNAME owned by "sub.foo.bar.example." and + "foo.bar.example.". There is a restriction in the DNAME definition + that no domain exist below a DNAME-owning domain; hence, the wildcard + DNAME is to be avoided. + + + + +Lewis Standards Track [Page 16] + +RFC 4592 DNSEXT WCARD July 2006 + + +4.5. SRV RRSet at a Wildcard Domain Name + + The definition of the SRV RRset is RFC 2782 [RFC2782]. In the + definition of the record, there is some confusion over the term + "Name". The definition reads as follows: + + # The format of the SRV RR + ... + # _Service._Proto.Name TTL Class SRV Priority Weight Port Target + ... + # Name + # The domain this RR refers to. The SRV RR is unique in that the + # name one searches for is not this name; the example near the end + # shows this clearly. + + Do not confuse the definition "Name" with the owner name. That is, + once removing the _Service and _Proto labels from the owner name of + the SRV RRSet, what remains could be a wildcard domain name but this + is immaterial to the SRV RRSet. + + For example, if an SRV record is the following: + + _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. + + *.example is a wildcard domain name and although it is the Name of + the SRV RR, it is not the owner (domain name). The owner domain name + is "_foo._udp.*.example.", which is not a wildcard domain name. + + A query for the SRV RRSet of "_foo._udp.bar.example." (class IN), + will result in a match of the name "*.example." (assuming there is no + bar.example.) and not a match of the SRV record shown. If there is + no SRV RRSet at "*.example.", the answer section will reflect that + (be empty or a CNAME RRset). + + The confusion is likely based on the mixture of the specification of + the SRV RR and the description of a "use case". + +4.6. DS RRSet at a Wildcard Domain Name + + A DS RRSet owned by a wildcard domain name is meaningless and + harmless. This statement is made in the context that an NS RRSet at + a wildcard domain name is undefined. At a non-delegation point, a DS + RRSet has no value (no corresponding DNSKEY RRSet will be used in + DNSSEC validation). If there is a synthesized DS RRSet, it alone + will not be very useful as it exists in the context of a delegation + point. + + + + + +Lewis Standards Track [Page 17] + +RFC 4592 DNSEXT WCARD July 2006 + + +4.7. NSEC RRSet at a Wildcard Domain Name + + Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet. + Synthesis of these records will only occur when the query exactly + matches the record. Synthesized NSEC RRs will not be harmful as they + will never be used in negative caching or to generate a negative + response [RFC2308]. + +4.8. RRSIG at a Wildcard Domain Name + + RRSIG records will be present at a wildcard domain name in a signed + zone and will be synthesized along with data sought in a query. The + fact that the owner name is synthesized is not a problem as the label + count in the RRSIG will instruct the verifying code to ignore it. + +4.9. Empty Non-terminal Wildcard Domain Name + + If a source of synthesis is an empty non-terminal, then the response + will be one of no error in the return code and no RRSet in the answer + section. + +5. 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 DNS, + security of the DNS, and extending the DNS to be more predictable. + +6. References + +6.1. Normative References + + [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, + October 1969. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + +Lewis Standards Track [Page 18] + +RFC 4592 DNSEXT WCARD July 2006 + + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +6.2. Informative References + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + +7. Others Contributing to the Document + + This document represents the work of a large working group. The + editor merely recorded its collective wisdom. + + Comments on this document can be sent to the editor or the mailing + list for the DNSEXT WG, namedroppers@ops.ietf.org. + +Editor's Address + + Edward Lewis + NeuStar + 46000 Center Oak Plaza + Sterling, VA + 20166, US + + Phone: +1-571-434-5468 + EMail: ed.lewis@neustar.biz + + + + + +Lewis Standards Track [Page 19] + +RFC 4592 DNSEXT WCARD July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Lewis Standards Track [Page 20] + |