diff --git a/bin/tests/system/checkconf/bad.conf b/bin/tests/system/checkconf/bad.conf new file mode 100644 index 0000000000..c3592e84a7 --- /dev/null +++ b/bin/tests/system/checkconf/bad.conf @@ -0,0 +1,52 @@ +/* + * Copyright (C) 2005 Internet Systems Consortium, Inc. ("ISC") + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: bad.conf,v 1.2 2005/06/23 06:52:23 marka Exp $ */ + +options { + avoid-v4-udp-ports { 100; } + avoid-v6-udp-ports { 100; }; + blackhole { 10.0.0.0/8; }; + coresize 1G; + datasize 100M; + deallocate-on-exit yes; + directory "."; + dump-file "named_dumpdb"; + fake-iquery yes; + files 1000; + has-old-clients no; + heartbeat-interval 30; + host-statistics yes; + host-statistics-max 100; + hostname none; + interface-interval 30; + listen-on port 90 { any; }; + listen-on port 100 { 127.0.0.1; }; + listen-on-v6 port 53 { none; }; + match-mapped-addresses yes; + memstatistics-file "named.memstats"; + multiple-cnames no; + named-xfer "this is no longer needed"; + pid-file none; + port 5300; + querylog yes; + recursing-file "named.recursing"; + random-device "/dev/random"; + recursive-clients 3000; + serial-queries 10; + serial-query-rate 100; + server-id none; +}; diff --git a/bin/tests/system/checkconf/good.conf b/bin/tests/system/checkconf/good.conf new file mode 100644 index 0000000000..aeb30bc4db --- /dev/null +++ b/bin/tests/system/checkconf/good.conf @@ -0,0 +1,56 @@ +/* + * Copyright (C) 2005 Internet Systems Consortium, Inc. ("ISC") + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: good.conf,v 1.2 2005/06/23 06:52:23 marka Exp $ */ + +/* + * This is just a random selection of configuration options. + */ + +options { + avoid-v4-udp-ports { 100; }; + avoid-v6-udp-ports { 100; }; + blackhole { 10.0.0.0/8; }; + coresize 1G; + datasize 100M; + deallocate-on-exit yes; + directory "."; + dump-file "named_dumpdb"; + fake-iquery yes; + files 1000; + has-old-clients no; + heartbeat-interval 30; + host-statistics yes; + host-statistics-max 100; + hostname none; + interface-interval 30; + listen-on port 90 { any; }; + listen-on port 100 { 127.0.0.1; }; + listen-on-v6 port 53 { none; }; + match-mapped-addresses yes; + memstatistics-file "named.memstats"; + multiple-cnames no; + named-xfer "this is no longer needed"; + pid-file none; + port 5300; + querylog yes; + recursing-file "named.recursing"; + random-device "/dev/random"; + recursive-clients 3000; + serial-queries 10; + serial-query-rate 100; + server-id none; +}; diff --git a/bin/tests/system/checkconf/tests.sh b/bin/tests/system/checkconf/tests.sh new file mode 100644 index 0000000000..b5ebe0891c --- /dev/null +++ b/bin/tests/system/checkconf/tests.sh @@ -0,0 +1,37 @@ +# Copyright (C) 2005 Internet Systems Consortium, Inc. ("ISC") +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: tests.sh,v 1.1 2005/06/23 06:52:23 marka Exp $ + +SYSTEMTESTTOP=.. +. $SYSTEMTESTTOP/conf.sh + +status=0 + +echo "I: checking that named-checkconf handles a known good config" + +ret=0 +$CHECKCONF good.conf > /dev/null 2>&1 || ret=1 +if [ $ret != 0 ]; then echo "I:failed"; fi +status=`expr $status + $ret` + +echo "I: checking that named-checkconf handles a known bad config" + +ret=1 +$CHECKCONF bad.conf > /dev/null 2>&1 || ret=0 +if [ $ret != 0 ]; then echo "I:failed"; fi +status=`expr $status + $ret` + +echo "I:exit status: $status" +exit $status diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-07.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-07.txt new file mode 100644 index 0000000000..7f6f5a818b --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-wcard-clarify-07.txt @@ -0,0 +1,861 @@ +DNSEXT Working Group E. Lewis +INTERNET DRAFT NeuStar +Expiration Date: November 16, 2005 May 16, 2005 + + The Role of Wildcards + in the Domain Name System + draft-ietf-dnsext-wcard-clarify-07.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that + any applicable patent or other IPR claims of which he or she is + aware have been or will be disclosed, and any of which he or she + becomes aware will be disclosed, in accordance with Section 6 of + BCP 79. + + 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 + + This Internet-Draft will expire on November 16, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This is an update to the wildcard definition of RFC 1034. The + interaction with wildcards and CNAME is changed, an error + condition 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. + +1 Introduction + + In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the + synthesis of answers from special resource records 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 has been given to minimize any + backwards compatibility with implementations that have complied + with RFC 1034's definition. + + This document is focused on the concept of wildcards as defined + in RFC 1034. Nothing is implied regarding alternative approaches, + nor are alternatives discussed. + +1.1 Motivation + + Many DNS implementations have diverged with respect to wildcards + in different ways from the original definition, or at from least + what had been intended. 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 changes, only those based on + implementation experience, and to remain as close to the original + document as possible. To reinforce this, relevant sections of RFC + 1034 are repeated verbatim to help compare the old and new text. + +1.2 The Original Definition + + The context of the wildcard concept involves 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). + + The beginning of the discussion ought to start with 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 appears after 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 3c 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 passage. + +# 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 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 This Document + + This document accomplishes these three items. + o Defines new terms + o Makes minor changes to avoid conflicting concepts + o Describes the actions of certain resource records as wildcards + +1.3.1 New Terms + + To help in discussing what resource records are wildcards, two + terms will be defined - "asterisk label" and "wild card 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, 4.3.2, "source of synthesis" and "closest + encloser" are defined. These definitions are in section 3.3.2. + "Label match" is defined in section 3.2. + + The introduction of new terms ought not have an impact on any + existing implementations. The new terms are used only to make + discussions of wildcards clearer. + +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 + there was no discussion of how to enforce the restriction. + +1.3.3 Considerations with Special Types + + This document describes semantics of wildcard CNAME RRSets + [RFC2181], wildcard NS RRSets, wildcard SOA RRSets, wildcard + DNAME RRSets [RFC2672], wildcard DS RRSets [RFC TBD], and empty + non-terminal wildcards. Understanding these types 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. + +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 '#' in the leftmost + column. + +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]. This feature has been underappreciated 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 "Wild Card Domain Name." + +2.1.1 Wild Card Domain Name and Asterisk Label + + A "wild card domain name" is defined by having its initial + (i.e., left-most 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, 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 wild card domain name." + +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 wild + card domain names. Labels such as 'the*' and '**' are not + asterisk labels, they do not start wild card domain names. + +2.1.3 Non-terminal Wild Card Domain Names + + In section 4.3.3, the following is stated: + +# .......................... The owner name of the wildcard RRs is of +# the form "*.", where is any domain name. +# should not contain other * labels...................... + + This restriction is lifted because the original documentation of it + is incomplete and the restriction does not serve any purpose given + years of operational experience. + + Indirectly, the above passage raises questions about wild card + domain names having subdomains and possibly being an empty + non-terminal. By thinking of domain names such as + "*.example.*.example." and "*.*.example." and focusing on the + right-most asterisk label in each, the issues become apparent. + + Although those example names have been restricted per RFC 1034, + a name such as "example.*.example." illustrates the same problems. + The sticky issue of subdomains and empty non-terminals is not + removed by the restriction. With that conclusion, the restriction + appears to be meaningless, worse yet, it implies that an + implementation would have to perform checks that do little more + than waste CPU cycles. + + A wild card 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 wild card 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. For example, if a wildcard + + RFC 1034 also refers to non-existence in the process of generating + a response that results in a return code of "name error." + NXDOMAIN is introduced in RFC 2308, section 2.1 says "In this + case the domain ... does not exist." The overloading of the term + "existence" is confusing. + + For the purposes of this document, a domain name is said to + exist if it plays a role in the execution of the algorithms in + RFC 1034. This document avoids discussion determining when an + authoritative name error has occurred. + +2.2.1 An Example + + To illustrate what is meant by existence consider this complete + zone: + + $ORIGIN example. + example. 3600 IN SOA + example. 3600 NS ns.example.com. + example. 3600 NS ns.example.net. + *.example. 3600 TXT "this is a wild card" + *.example. 3600 MX 10 host1.example. + sub.*.example. 3600 TXT "this is not a wild card" + host1.example. 3600 A 192.0.4.1 + _ssh._tcp.host1.example. 3600 SRV + _ssh._tcp.host2.example. 3600 SRV + 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 queries would be synthesized from one of the + wildcards: + + 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.' + + 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 queries would not be synthesized from any of the + wildcards: + + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + + QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN + because *.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) + +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 a 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." + + 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, this is not the intent of the original document. + +2.2.3 Yet Another Definition of Existence + + RFC1034'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 on RRSet. A node may have no RRSets + if it has descendents that do, this node is a empty non-terminal. + A node may have its own RRSets and have descendants with RRSets + too. + + 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. 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. + +2.3 When does a Wild Card Domain Name is not Special + + When a wild card domain name appears in a message's query section, + no special processing occurs. An asterisk label in a query name + only (label) matches an asterisk label in the existing zone tree + when the 4.3.2 algorithm is being followed. + + When a wild card 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 Wild Card Domain Name On a Response + + The description of how wildcards 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 in RFC 1034, section 4.3.2. is not intended to be + pseudo code, i.e., its steps are not intended to be followed in + strict order. The "algorithm" is a suggestion. As such, in + step 3, parts a, b, and c, do not have to be implemented in + that order. + +3.1 Step 2 + + Step 2 of the RFC 1034's 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 be ever be used for + synthesis. + +3.2 Step 3 + + Step 3 is dominated by three parts, labelled '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. It is + possible, from the description given, that a query might fit + into both part a and part b, this is not within the scope of + this document. + +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 wild card 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 wild card domain name immediately descending + from the closest encloser, provided that this wild card domain + name exists. "Immediately descending" means that the source + of synthesis has a name of the form: + .. + 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, the lookup does not look for other wildcard records. + +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 + _telnet._tcp.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 step + 'a' and step 'c' a change to this passage has been made. + + The change is to add the following text to step 'c': + + 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 step a covering the + processing of CNAME RRSets. + +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 are 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," i.e., empty non-terminal wild card domain names. + +4.1 SOA RRSet at a Wild Card Domain Name + + A wild card domain name owning an SOA RRSet means that the + domain is at the root of the zone (apex). The domain can not + be a source of synthesis because that is, by definition, a + descendent node (of the closest encloser) and a zone apex is + at the top of the zone. + + Although a wild card 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. + + E.g., given this zone: + $ORIGIN *.example. + @ 3600 IN SOA + 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 reason is that the asterisk + label only becomes significant when RFC 1034's 4.3.2, step 3 + part 'c' in 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 Wild Card Domain Name + + With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now + in place, the semantics of a wild card domain name owning an + NS RR 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) become unclear. + + After some lengthy discussions, there has been no clear "best + answer" on how to document the semantics of such a situation. + Barring such records from the DNS would require definition of + rules for that, as well as introducing a restriction on records + that were once legal. Allowing such records and amending the + process of signature management would entail complicating the + DNSSEC definition. + + Combining these observations with thought that a wild card + domain name owning an NS record is an operationally uninteresting + scenario, i.e., it won't happen in the normal course of events, + accomodating this situation in the specification would also be + categorized as "needless complication." Further, expending more + effort on this topic has proven to be an exercise in diminishing + returns. + + In summary, there is no definition given for wild card 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 wild + card NS RRSets in a zone is discouraged, but not barred. + +4.3 CNAME RRSet at a Wild Card Domain Name + + The issue of a CNAME RRSet owned by a wild card 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 Wild Card Domain Name + + Ownership of a DNAME RRSet by a wild card 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 record "a.b.example. DNAME foo.bar.tld." and another + cache obtains "b.example. DNAME foo.bar.tld.", both generated + from the record "*.example. DNAME foo.bar.tld." 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 some, it is 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, an operational nightmare ensues. + + Another justification for banning or avoiding 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 not to be permitted. + +4.5 SRV RRSet at a Wild Card 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 a domain name. I.e., + once removing the _Service and _Proto labels from the owner name + of the SRV RRSet, what remains could be a wild card domain name + but this is immaterial to the SRV RRSet. + + E.g., If an SRV record is: + _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. + + *.example is a wild card domain name and although it it 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 wild card + domain name. + + 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 Wild Card Domain Name + + A DS RRSet owned by a wild card domain name is meaningless and + harmless. + +4.7 NSEC RRSet at a Wild Card Domain Name + + Wild card 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 RR's will not + be harmful as they will never be used in negative caching or to + generate a negative response. + +4.8 RRSIG at a Wild Card Domain Name + + RRSIG records will be present at a wild card 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 Wild Card 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. IANA Considerations + + None. + +7. References + + Normative References + + [RFC20] ASCII Format for Network Interchange, V.G. Cerf, + Oct-16-1969 + + [RFC1034] Domain Names - Concepts and Facilities, + P.V. Mockapetris, Nov-01-1987 + + [RFC1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 + + [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 + + [RFC2119] Key Words for Use in RFCs to Indicate Requirement + Levels, S Bradner, March 1997 + + [RFC2181] Clarifications to the DNS Specification, R. Elz and + R. Bush, July 1997 + + [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), + M. Andrews, March 1998 + + [RFC2782] A DNS RR for specifying the location of services (DNS + SRV), A. Gulbrandsen, et.al., February 2000 + + [RFC4033] DNS Security Introduction and Requirements, R. Arends, + et.al., March 2005 + + [RFC4034] Resource Records for the DNS Security Extensions, + R. Arends, et.al., March 2005 + + [RFC4035] Protocol Modifications for the DNS Security Extensions, + R. Arends, et.al., March 2005 + + [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, + August 1999 + + Informative References + + [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), + P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + April 1997 + +8. Editor + + Name: Edward Lewis + Affiliation: NeuStar + Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US + Phone: +1-571-434-5468 + Email: ed.lewis@neustar.biz + + Comments on this document can be sent to the editor or the mailing + list for the DNSEXT WG, namedroppers@ops.ietf.org. + +9. Others Contributing to the Document + + This document represents the work of a large working group. The + editor merely recorded the collective wisdom of the working group. + +10. Trailing Boilerplate + + Copyright (C) The Internet Society (2005). + + 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 currently provided by the + Internet Society. + +Expiration + + This document expires on or about November 16, 2005. \ No newline at end of file diff --git a/doc/rfc/rfc4074.txt b/doc/rfc/rfc4074.txt new file mode 100644 index 0000000000..d9252b39eb --- /dev/null +++ b/doc/rfc/rfc4074.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group Y. Morishita +Request for Comments: 4074 JPRS +Category: Informational T. Jinmei + Toshiba + May 2005 + + + Common Misbehavior Against DNS Queries for IPv6 Addresses + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + There is some known misbehavior of DNS authoritative servers when + they are queried for AAAA resource records. Such behavior can block + IPv4 communication that should actually be available, cause a + significant delay in name resolution, or even make a denial of + service attack. This memo describes details of known cases and + discusses their effects. + +1. Introduction + + Many existing DNS clients (resolvers) that support IPv6 first search + for AAAA Resource Records (RRs) of a target host name, and then for A + RRs of the same name. This fallback mechanism is based on the DNS + specifications, which if not obeyed by authoritative servers, can + produce unpleasant results. In some cases, for example, a web + browser fails to connect to a web server it could otherwise reach. + In the following sections, this memo describes some typical cases of + such misbehavior and its (bad) effects. + + Note that the misbehavior is not specific to AAAA RRs. In fact, all + known examples also apply to the cases of queries for MX, NS, and SOA + RRs. The authors believe this can be generalized for all types of + queries other than those for A RRs. In this memo, however, we + concentrate on the case for AAAA queries, since the problem is + particularly severe for resolvers that support IPv6, which thus + affects many end users. Resolvers at end users normally send A + and/or AAAA queries only, so the problem for the other cases is + relatively minor. + + + +Morishita & Jinmei Informational [Page 1] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +2. Network Model + + In this memo, we assume a typical network model of name resolution + environment using DNS. It consists of three components: stub + resolvers, caching servers, and authoritative servers. A stub + resolver issues a recursive query to a caching server, which then + handles the entire name resolution procedure recursively. The + caching server caches the result of the query and sends the result to + the stub resolver. The authoritative servers respond to queries for + names for which they have the authority, normally in a non-recursive + manner. + +3. Expected Behavior + + Suppose that an authoritative server has an A RR but has no AAAA RR + for a host name. Then, the server should return a response to a + query for an AAAA RR of the name with the response code (RCODE) being + 0 (indicating no error) and with an empty answer section (see + Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that + there is at least one RR of a different type than AAAA for the + queried name, and the stub resolver can then look for A RRs. + + This way, the caching server can cache the fact that the queried name + has no AAAA RR (but may have other types of RRs), and thus improve + the response time to further queries for an AAAA RR of the name. + +4. Problematic Behaviors + + There are some known cases at authoritative servers that do not + conform to the expected behavior. This section describes those + problematic cases. + +4.1. Ignore Queries for AAAA + + Some authoritative servers seem to ignore queries for an AAAA RR, + causing a delay at the stub resolver to fall back to a query for an A + RR. This behavior may cause a fatal timeout at the resolver or at + the application that calls the resolver. Even if the resolver + eventually falls back, the result can be an unacceptable delay for + the application user, especially with interactive applications like + web browsing. + +4.2. Return "Name Error" + + This type of server returns a response with RCODE 3 ("Name Error") to + a query for an AAAA RR, indicating that it does not have any RRs of + any type for the queried name. + + + + +Morishita & Jinmei Informational [Page 2] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + + With this response, the stub resolver may immediately give up and + never fall back. Even if the resolver retries with a query for an A + RR, the negative response for the name has been cached in the caching + server, and the caching server will simply return the negative + response. As a result, the stub resolver considers this to be a + fatal error in name resolution. + + Several examples of this behavior are known to the authors. As of + this writing, all have been fixed. + +4.3. Return Other Erroneous Codes + + Other authoritative servers return a response with erroneous response + codes other than RCODE 3 ("Name Error"). One such RCODE is 4 ("Not + Implemented"), indicating that the servers do not support the + requested type of query. + + These cases are less harmful than the previous one; if the stub + resolver falls back to querying for an A RR, the caching server will + process the query correctly and return an appropriate response. + + However, these can still cause a serious effect. There was an + authoritative server implementation that returned RCODE 2 ("Server + failure") to queries for AAAA RRs. One widely deployed mail server + implementation with a certain type of resolver library interpreted + this result as an indication of retry and did not fall back to + queries for A RRs, causing message delivery failure. + + If the caching server receives a response with these response codes, + it does not cache the fact that the queried name has no AAAA RR, + resulting in redundant queries for AAAA RRs in the future. The + behavior will waste network bandwidth and increase the load of the + authoritative server. + + Using RCODE 1 ("Format error") would cause a similar effect, though + the authors have not seen such implementations yet. + +4.4. Return a Broken Response + + Another type of authoritative servers returns broken responses to + AAAA queries. Returning a response whose RR type is AAAA with the + length of the RDATA being 4 bytes is a known behavior of this + category. The 4-byte data looks like the IPv4 address of the queried + host name. + + + + + + + +Morishita & Jinmei Informational [Page 3] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + + That is, the RR in the answer section would be described as follows: + + www.bad.example. 600 IN AAAA 192.0.2.1 + + which is, of course, bogus (or at least meaningless). + + A widely deployed caching server implementation transparently returns + the broken response (and caches it) to the stub resolver. Another + known server implementation parses the response by itself, and sends + a separate response with RCODE 2 ("Server failure"). + + In either case, the broken response does not affect queries for an A + RR of the same name. If the stub resolver falls back to A queries, + it will get an appropriate response. + + The latter case, however, causes the same bad effect as that + described in the previous section: redundant queries for AAAA RRs. + +4.5. Make Lame Delegation + + Some authoritative servers respond to AAAA queries in a way that + causes lame delegation. In this case, the parent zone specifies that + the authoritative server should have the authority of a zone, but the + server should not return an authoritative response for AAAA queries + within the zone (i.e., the AA bit in the response is not set). On + the other hand, the authoritative server returns an authoritative + response for A queries. + + When a caching server asks the server for AAAA RRs in the zone, it + recognizes the delegation is lame, and returns a response with RCODE + 2 ("Server failure") to the stub resolver. + + Furthermore, some caching servers record the authoritative server as + lame for the zone and will not use it for a certain period of time. + With this type of caching server, even if the stub resolver falls + back to querying for an A RR, the caching server will simply return a + response with RCODE 2, since all the servers are known to be "lame." + + There is also an implementation that relaxes the behavior a little + bit. It tries to avoid using the lame server, but continues to try + it as a last resort. With this type of caching server, the stub + resolver will get a correct response if it falls back after Server + failure. However, this still causes redundant AAAA queries, as + explained in the previous sections. + + + + + + + +Morishita & Jinmei Informational [Page 4] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +5. Security Considerations + + The CERT/CC pointed out that the response with RCODE 3 ("Name + Error"), described in Section 4.2, can be used for a denial of + service attack [2]. The same argument applies to the case of "lame + delegation", described in Section 4.5, with a certain type of caching + server. + +6. Acknowledgements + + Erik Nordmark encouraged the authors to publish this document as an + RFC. Akira Kato and Paul Vixie reviewed a preliminary version of + this document. Pekka Savola carefully reviewed a previous version + and provided detailed comments. Bill Fenner, Scott Hollenbeck, + Thomas Narten, and Alex Zinin reviewed and helped improve the + document at the last stage for publication. + +7. Informative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from + AAAA queries could cause denial-of-service conditions", + March 2003, . + +Authors' Addresses + + MORISHITA Orange Yasuhiro + Research and Development Department, Japan Registry Services Co.,Ltd. + Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda + Chiyoda-ku, Tokyo 101-0065 + Japan + + EMail: yasuhiro@jprs.co.jp + + + JINMEI Tatuya + Corporate Research & Development Center, Toshiba Corporation + 1 Komukai Toshiba-cho, Saiwai-ku + Kawasaki-shi, Kanagawa 212-8582 + Japan + + EMail: jinmei@isl.rdc.toshiba.co.jp + + + + + + + +Morishita & Jinmei Informational [Page 5] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + 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 currently provided by the + Internet Society. + + + + + + + +Morishita & Jinmei Informational [Page 6] +