diff --git a/README b/README index d79a6b9904..da800c5947 100644 --- a/README +++ b/README @@ -368,27 +368,31 @@ Building We've had successful builds and tests on the following systems: COMPAQ Tru64 UNIX 5.1B + Fedora Core 6 FreeBSD 4.10, 5.2.1, 6.2 HP-UX 11.11 - NetBSD 1.5 - Slackware Linux 8.1 - Solaris 8, 9, 9 (x86) + Mac OS X 10.5 + NetBSD 3.x and 4.0-beta + OpenBSD 3.3 and up + Solaris 8, 9, 9 (x86), 10 + Ubuntu 7.04, 7.10 Windows NT/2000/XP/2003 - Additionally, we have unverified reports of success building - previous versions of BIND 9 from users of the following systems: + We have recent reports from the user community that a supported + version of BIND will build and run on the following systems: - AIX 5L - SuSE Linux 7.0 - Slackware Linux 7.x, 8.0 - Red Hat Linux 7.1 - Debian GNU/Linux 2.2 and 3.0 - Mandrake 8.1 - OpenBSD 2.6, 2.8, 2.9, 3.1, 3.6, 3.8 - UnixWare 7.1.1 - HP-UX 10.20 - BSD/OS 4.2 - Mac OS X 10.1, 10.3.8 + AIX 4.3, 5L + CentOS 4, 4.5, 5 + Darwin 9.0.0d1/ARM + Debian 4 + Fedora Core 5, 7 + FreeBSD 6.1 + HP-UX 11.23 PA + MacOS X 10.4, 10.5 + Red Hat Enterprise Linux 4, 5 + SCO OpenServer 5.0.6 + Slackware 9, 10 + SuSE 9, 10 To build, just diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-04.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-04.txt deleted file mode 100644 index b37d625722..0000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-04.txt +++ /dev/null @@ -1,1792 +0,0 @@ - - - -DNS Extensions Working Group S. Rose -Internet-Draft NIST -Intended status: Standards Track W. Wijngaards -Expires: February 11, 2008 NLnet Labs - August 10, 2007 - - - Update to DNAME Redirection in the DNS - draft-ietf-dnsext-rfc2672bis-dname-04 - -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 February 11, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - The DNAME record provides redirection for a sub-tree of the domain - name tree in the DNS system. That is, all names that end with a - particular suffix are redirected to another part of the DNS. This is - an update to the original specification in RFC 2672. - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 1] - -Internet-Draft DNAME Redirection August 2007 - - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3 - 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4 - 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5 - 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 5 - 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6 - - 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7 - 3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 7 - - 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 9 - - 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 11 - 5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 11 - 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 11 - 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 11 - 5.3.1. DNAME bit in NSEC/NSEC3 type map . . . . . . . . . . . 11 - 5.3.2. Other issues with NSEC3 and DNAME . . . . . . . . . . 12 - 5.3.3. Validators Must Understand DNAME . . . . . . . . . . . 12 - 5.3.3.1. DNAME in Bitmap Causes Invalid Name Error . . . . 12 - 5.3.3.2. Valid Name Error Response Involving DNAME in - Bitmap . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3.3.3. Response With Synthesized CNAME . . . . . . . . . 13 - - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 2] - -Internet-Draft DNAME Redirection August 2007 - - -1. Introduction - - DNAME is a DNS Resource Record type. DNAME provides redirection from - a part of the DNS name tree to another part of the DNS name tree. - - For example, given a query for foo.example.com and a DNAME from - example.com to example.net, the query would be redirected to - foo.example.net. With the same DNAME a query for foo.bar.example.com - would be redirected to foo.bar.example.net. - - The DNAME RR is similar to the CNAME RR in that it provides - redirection. The CNAME RR only provides redirection for exactly one - name while the DNAME RR provides redirection for all names in a sub- - tree of the DNS name tree. - - This document is an update to the original specification of DNAME in - RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of - maintaining address-to-name mappings in a context of network - renumbering. So that with a careful set-up a renumbering event in - the network causes no change to the authoritative server that has the - address-to-name mappings. Examples in practice are classless reverse - address space delegations and punycode alternates for domain spaces. - - Other usage of DNAME lies in redirection of name spaces. For - example, a zone administrator may want subtrees of the DNS to contain - the same information. DNAME is also used for redirection of ENUM - domains to another maintaining party. - - This update to DNAME does not change the wire format or the handling - of DNAME Resource Records by existing software. A new UD (Understand - Dname) bit in the EDNS flags field can be used to signal that CNAME - synthesis is not needed. Discussion is added on problems that may be - encountered when using DNAME. - -2. The DNAME Resource Record - -2.1. Format - - The DNAME RR has mnemonic DNAME and type code 39 (decimal). - - The format of the DNAME record has not changed from the original - specification in RFC 2672. DNAME has the following format: - - DNAME - - The format is not class-sensitive. All fields are required. The - RDATA field target is a domain name. The RDATA field target name - MUST be sent uncompressed [RFC3597]. - - - -Rose & Wijngaards Expires February 11, 2008 [Page 3] - -Internet-Draft DNAME Redirection August 2007 - - - The DNAME RR causes type NS additional section processing. - -2.2. The DNAME Substitution - - DNAMEs cause a name substitution to happen to query names. This is - called the DNAME substitution. The suffix owner name of the DNAME is - replaced by the target of the DNAME. The owner name of the DNAME is - not itself redirected, only domain names below the owner name are - redirected. Only whole labels are replaced. A name is considered - below the owner name if it has more labels than the owner name, and - the labels of the owner name appear as the suffix of the name. See - the table of examples for common cases and corner cases. - - In the table below, the QNAME refers to the query name. The owner is - the DNAME owner domain name, and the target refers to the target of - the DNAME record. The result is the resulting name after performing - the DNAME substitution on the query name. "no match" means that the - query did not match the DNAME and thus no substitution is performed - and a possible error message is returned (if no other result is - possible). In the examples below, 'cyc' and 'shortloop' contain - loops. - - QNAME owner DNAME target result - ---------------- -------------- -------------- ----------------- - com. example.com. example.net. - example.com. example.com. example.net. - a.example.com. example.com. example.net. a.example.net. - a.b.example.com. example.com. example.net. a.b.example.net. - ab.example.com. b.example.com. example.net. - foo.example.com. example.com. example.net. foo.example.net. - a.x.example.com. x.example.com. example.net. a.example.net. - a.example.com. example.com. y.example.net. a.y.example.net. - cyc.example.com. example.com. example.com. cyc.example.com. - cyc.example.com. example.com. c.example.com. cyc.c.example.com. - shortloop.x.x. x. . shortloop.x. - shortloop.x. x. . shortloop. - - Table 1. DNAME Substitution Examples. - - It is possible for DNAMEs to form loops. Just like CNAMEs can form - loops. DNAMEs and CNAMEs can chain together to form loops. A single - corner case DNAME can form a loop. Resolvers and servers should be - cautious in devoting resources to a query, but be aware that fairly - long chains of DNAMEs may be valid. Zone content administrators - should take care to insure that there are no loops that could occur - when using DNAME or DNAME/CNAME redirection. - - The domain name can get too long during substitution. For example, - - - -Rose & Wijngaards Expires February 11, 2008 [Page 4] - -Internet-Draft DNAME Redirection August 2007 - - - suppose the target name of the DNAME RR is 250 octets in length - (multiple labels), if an incoming QNAME that has a first label over 5 - octets in length, the result of the result would be a name over 255 - octets. If this occurs the server returns an RCODE of YXDOMAIN - [RFC2136]. The DNAME record and its signature (if the zone is - signed) are included in the answer as proof for the YXDOMAIN (value - 6) RCODE. - -2.3. DNAME Apex not Redirected itself - - The owner name of a DNAME is not redirected itself. The reason for - the original decision was that one can have a DNAME at the zone apex - without problem. Then use this DNAME at the zone apex to point - queries to the target zone. There still is a need to have the - customary SOA and NS resource records at the zone apex. This means - that DNAME does not mirror a zone completely, as it does not mirror - the zone apex. - - Another reason for excluding the DNAME owner from the DNAME - substitution is that one can then query for the DNAME through RFC - 1034 [RFC1034] caches. - - This means that a DNAME RR is not allowed at the same domain name as - NS records unless there is also a SOA record present. DNAME RRs are - not allowed at the parent side of a delegation point but are allowed - at a zone apex. - -2.4. Names Next to and Below a DNAME Record - - Other resource records MUST NOT exist below the owner of a DNAME RR. - To get the contents for names subordinate to that owner, the DNAME - redirection must be invoked and the resulting target queried. A - server SHOULD refuse to load a zone that has data below a domain name - owning a DNAME RR. Also a server SHOULD refuse to load a zone - subordinate to the owner of a DNAME record in the ancestor zone. - - DNAME is a singleton type, meaning only one DNAME is allowed per - name. The owner name of a DNAME can only have one DNAME RR, and no - CNAME RRs can exist at that name. These rules make sure that for a - single domain name only one redirection exists, and thus no confusion - which one to follow. A server SHOULD refuse to load a zone that - violates these rules. - - The domain name that owns a DNAME record is allowed to have other - resource record types at that domain name, except DNAMEs or CNAMEs. - - These rules allow DNAME records to be queried through DNAME unaware - caches. - - - -Rose & Wijngaards Expires February 11, 2008 [Page 5] - -Internet-Draft DNAME Redirection August 2007 - - -2.5. Compression of the DNAME record. - - The DNAME owner name can be compressed like any other owner name. - The DNAME RDATA target name MUST NOT be sent out in compressed form, - so that a DNAME RR can be treated as an unknown type. - - Although the previous specification [RFC2672] talked about signaling - to allow compression of the target name, no such signaling is - explicitly specified. - - RFC2672 stated that the EDNS version had a meaning for understanding - of DNAME and DNAME target name compression. This document updates - RFC2672, in that there is no EDNS version signaling for DNAME as of - yet. However, the flags section of EDNS(0) is updated with a - Understand-DNAME flag by this document (See Section 3.2). - -3. Processing - -3.1. Wildcards - - The use of DNAME in conjunction with wildcards is discouraged - [RFC4592]. Thus records of the form "*.example.com DNAME - example.net" SHOULD NOT be used. - - The interaction between the expansion of the wildcard and the - redirection of the DNAME is non-deterministic. Because the - processing is non-deterministic, DNSSEC validating resolvers may not - be able to validate a wildcarded DNAME. - - A server MAY give a warning that the behavior is unspecified if such - a wildcarded DNAME is loaded. - -3.2. CNAME synthesis - - On the server side, the DNAME RR record is always included in the - answer section of a query. A CNAME RR record with TTL 0 is - synthesized for old resolvers, specifically for the QNAME in the - query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the - synthesized CNAME does not have to be signed. The DNAME has an RRSIG - and a validating resolver can check the CNAME against the DNAME - record and validate the DNAME record. - - It does not make sense for the authoritative server to follow the - chain of DNAMEs, CNAMEs and wildcards outside of the zone of the - query, as modern resolvers will remove out-of-zone information from - the answer. - - Resolvers MUST be able to handle a synthesized CNAME TTL of zero or - - - -Rose & Wijngaards Expires February 11, 2008 [Page 6] - -Internet-Draft DNAME Redirection August 2007 - - - equal to the TTL of the corresponding DNAME record. The TTL of zero - means that the CNAME can be discarded immediately after processing - the answer. DNSSEC aware resolvers can set the Understand-DNAME (UD - bit) to receive a response with only the DNAME RR and no synthesized - CNAMEs. - - The UD bit is part of the EDNS extended RCODE and Flags field. It is - used to omit server processing, transmission and resolver processing - the unsigned synthesized CNAMEs when DNSSEC validation is performed. - Resolvers can set this in a query to request omission of the - synthesized CNAMEs. Servers copy the UD bit to the response, and can - omit synthesized CNAMEs from the answer. Older resolvers do not set - the UD bit, and older servers do not copy the UD bit to the answer, - and will not omit synthesized CNAMEs. - - Updated EDNS extended RCODE and Flags field. - - +0 (MSB) +1 (LSB) - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 0: | EXTENDED-RCODE | VERSION | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 2: |DO|UD| Z | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - Servers MUST be able to answer a query for a synthesized CNAME. An - answer containing the synthesized CNAME cannot contain an error - (since a CNAME has been followed), as per RFC 1034 CNAME rules. - -3.3. Acceptance and Intermediate Storage - - DNS Caches MUST NOT allow data to be cached below the owner of a - DNAME RR, except CNAME records or perhaps NSEC3 records and their - signatures. CNAME records below the owner of a DNAME MUST be re- - synthesized from the DNAME, or checked against the DNAME record - before sending them out. This improves consistency of the DNAME and - CNAME records below the owner of the DNAME. - - DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant - clients. A DNS Cache that understands DNAMEs can send out queries on - behalf of clients with the UD bit set. After receiving the answers - the DNS Cache sends replies to DNAME ignorant clients that include - DNAMEs and synthesized CNAMEs. - -3.4. Server algorithm - - Below the server algorithm, which appeared in RFC 2672 Section 4.1, - is expanded to handle the UD bit. - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 7] - -Internet-Draft DNAME Redirection August 2007 - - - 1. Set or clear the value of recursion available in the response - depending on whether the name server is willing to provide - recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, otherwise - step 2. - 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. - 3. Start matching down, label by label, in the zone. The matching - process can terminate several ways: - A. If the whole of QNAME is matched, we have found the node. - - If the data at the node is a CNAME, and QTYPE does not match - CNAME, copy the CNAME RR into the answer section of the - response, change QNAME to the canonical name in the CNAME RR, - and go back to step 1. - - Otherwise, copy all RRs which match QTYPE into the answer - section and go to step 6. - B. If a match would take us out of the authoritative data, we - have a referral. This happens when we encounter a node with - NS RRs marking cuts along the bottom of a zone. - - Copy the NS RRs for the subzone into the authority section of - the reply. Put whatever addresses are available into the - additional section, using glue RRs if the addresses are not - available from authoritative data or the cache. Go to step - 4. - C. If at some label, a match is impossible (i.e., the - corresponding label does not exist), look to see whether the - last label matched has a DNAME record. - - If a DNAME record exists at that point, copy that record into - the answer section. If substitution of its for its - in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise - perform the substitution and continue. If the EDNS OPT - record is present in the query and the UD bit is set, the - server MAY copy the UD bit to the answer EDNS OPT record, and - omit CNAME synthesis. Else the server MUST synthesize a - CNAME record as described above and include it in the answer - section. Go back to step 1. - - If there was no DNAME record, look to see if the "*" label - exists. - - If the "*" label does not exist, check whether the name we - are looking for is the original QNAME in the query or a name - - - -Rose & Wijngaards Expires February 11, 2008 [Page 8] - -Internet-Draft DNAME Redirection August 2007 - - - we have followed due to a CNAME or DNAME. 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. If the data at the node with the "*" label 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. Otherwise, Go to step 6. - - 4. Start matching down in the cache. If QNAME is found in the - cache, copy all RRs attached to it that match QTYPE into the - answer section. If QNAME is not found in the cache but a DNAME - record is present at an ancestor of QNAME, copy that DNAME record - into the answer section. If there was no delegation from - authoritative data, look for the best one from the cache, and put - it in the authority section. Go to step 6. - 5. Use the local resolver or a copy of its algorithm to answer the - query. Store the results, including any intermediate CNAMEs and - DNAMEs, in the answer section of the response. - 6. Using local data only, attempt to add other RRs which may be - useful to the additional section of the query. Exit. - - Note that there will be at most one ancestor with a DNAME as - described in step 4 unless some zone's data is in violation of the - no-descendants limitation in section 3. An implementation might take - advantage of this limitation by stopping the search of step 3c or - step 4 when a DNAME record is encountered. - -4. DNAME Discussions in Other Documents - - In [RFC2181], in Section 10.3., the discussion on MX and NS records - touches on redirection by CNAMEs, but this also holds for DNAMEs. - - - - - - - - - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 9] - -Internet-Draft DNAME Redirection August 2007 - - - Excerpt from 10.3. MX and NS records (in RFC 2181). - - The domain name used as the value of a NS resource record, - or part of the value of a MX resource record must not be - an alias. Not only is the specification clear on this - point, but using an alias in either of these positions - neither works as well as might be hoped, nor well fulfills - the ambition that may have led to this approach. This - domain name must have as its value one or more address - records. Currently those will be A records, however in - the future other record types giving addressing - information may be acceptable. It can also have other - RRs, but never a CNAME RR. - - The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. - [RFC3363] does NOT RECOMMENDED the use of DNAME in the IPv6 reverse - tree. (Hence, all references to DNAME should have been removed from - [RFC4294].) Based on the experience gained in the meantime, RFC 3363 - should be revised, dropping all constraints on having DNAME RRs in - these zones. This would greatly improve the manageability of the - IPv6 reverse tree. These changes are made explicit below. - - In [RFC3363], section 4, DNAME is not recommended for the IPv6 - reverse tree. The opening premise of this section is demonstrably - wrong. Everything that follows from that premise is also invalid. - - In [RFC3363], the paragraph - - "The issues for DNAME in the reverse mapping tree appears to be - closely tied to the need to use fragmented A6 in the main tree: if - one is necessary, so is the other, and if one isn't necessary, the - other isn't either. Therefore, in moving RFC 2874 to experimental, - the intent of this document is that use of DNAME RRs in the reverse - tree be deprecated." - - is to be replaced with the word "DELETED". - - In [RFC4294], the reference to DNAME was left in as a editorial - oversight. The paragraph - - "Those nodes are NOT RECOMMENDED to support the experimental A6 and - DNAME Resource Records [RFC3363]." - - - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 10] - -Internet-Draft DNAME Redirection August 2007 - - - is to be replaced by - - "Those nodes are NOT RECOMMENDED to support the experimental - A6 Resource Record [RFC3363]." - -5. Other Issues with DNAME - - There are several issues to be aware of about the use of DNAME. - -5.1. MX, NS and PTR Records Must Point to Target of DNAME - - The names listed as target names of MX, NS and PTR records must be - canonical hostnames. This means no CNAME or DNAME redirection may be - present during DNS lookup of the address records for the host. This - is discussed in RFC 2181 [RFC2181], section 10.3, and RFC 1912 - [RFC1912], section 2.4. - - The upshot of this is that although the lookup of a PTR record can - involve DNAMEs, the name listed in the PTR record can not fall under - a DNAME. The same holds for NS and MX records. For example, when - punycode alternates for a zone use DNAME then the NS, MX and PTR - records that point to that zone must use names without punycode in - their RDATA. What must be done then is to have the domain names with - DNAME substitution already applied to it as the MX, NS, PTR data. - These are valid canonical hostnames. - -5.2. Dynamic Update and DNAME - - Zones containing a DNAME RR MUST NOT accept a dynamic update message - that would add a record or delegation with a name existing under a - DNAME. - - A server MUST return an error message with RCODE=REFUSED [RFC2136] in - response to a dynamic update message that would add a resource record - under a DNAME in the zone. - -5.3. DNSSEC and DNAME - -5.3.1. DNAME bit in NSEC/NSEC3 type map - - When a validator checks the NSEC/NSEC3 RRs returned on a name error - response, it SHOULD check that the DNAME bit is not set. If the - DNAME bit is set then the DNAME substitution should have been done, - but has not. - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 11] - -Internet-Draft DNAME Redirection August 2007 - - -5.3.2. Other issues with NSEC3 and DNAME - - NSEC3 records and their signatures are allowed to exist below the - owner name of a DNAME RR. This is because of the nature of NSEC3 RRs - in DNSSEC, which creates hashed owner names that exist below the apex - name of the zone. This is an exception to the rule that there MUST - NOT be any other RRs under the owner name of a DNAME RR, if the DNAME - RR is owned by the zone apex domain name. - - Queries for NSEC3 owner names are redirected as if there were no such - NSEC3 present. - - There is no significant extra hashing cost for NSEC3 signed zones - when answering queries with DNAME substitution. - -5.3.3. Validators Must Understand DNAME - - Examples of why DNSSEC validators MUST understand DNAME. - -5.3.3.1. DNAME in Bitmap Causes Invalid Name Error - - ;; Header: QR AA DO RCODE=3(NXDOMAIN) - ;; Question - foo.bar.example.com. IN A - ;; Answer - bar.example.com. NSEC dub.example.com. A DNAME - bar.example.com. RRSIG NSEC [valid signature] - - If this is the response, then only by understanding that the DNAME - bit means that foo.bar.example.com needed to have been redirected by - the DNAME, the validator can see that it is a BOGUS reply from an - attacker that collated existing records from the DNS to create a - confusing reply. - - If the DNAME bit had not been set in the NSEC record above then the - answer would have validated as a correct name error response. - -5.3.3.2. Valid Name Error Response Involving DNAME in Bitmap - - - - - - - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 12] - -Internet-Draft DNAME Redirection August 2007 - - - ;; Header: QR AA DO RCODE=3(NXDOMAIN) - ;; Question - cee.example.com. IN A - ;; Answer - bar.example.com. NSEC dub.example.com. A DNAME - bar.example.com. RRSIG NSEC [valid signature] - - If the query had been cee.example.com as shown above, then this - answer would have been validated, because 'cee' does not get - redirected by the DNAME at 'bar'. - -5.3.3.3. Response With Synthesized CNAME - - ;; Header: QR AA DO RCODE=0(NOERROR) - ;; Question - foo.bar.example.com. IN A - ;; Answer - bar.example.com. DNAME bar.example.net. - bar.example.com. RRSIG DNAME [valid signature] - foo.bar.example.com. CNAME foo.bar.example.net. - - The answer shown above has the synthesized CNAME included. However, - the CNAME has no signature, since the server does not sign online (it - is a slow operation and exposes the signing key). So it cannot be - trusted. It could be altered by an attacker to be - foo.bar.example.com CNAME bla.bla.example. The DNAME record does - have its signature included, since it does not change for every query - name. The validator must verify the DNAME signature and then - recursively resolve further to query for the foo.bar.example.net A - record. - -6. IANA Considerations - - The main purpose of this draft is to discuss issues related to the - use of DNAME RRs in a DNS zone. The original document registered the - DNAME Resource Record type code 39 (decimal). IANA should update the - DNS resource record registry by adding a pointer to this document for - RR type 39. - - This draft requests the second highest bit in the EDNS flags field - for the Understand-DNAME (UD) flag. - -7. Security Considerations - - DNAME redirects queries elsewhere, which may impact security based on - policy and the security status of the zone with the DNAME and the - redirection zone's security status. - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 13] - -Internet-Draft DNAME Redirection August 2007 - - - If a validating resolver accepts wildcarded DNAMEs, this creates - security issues. Since the processing of a wildcarded DNAME is non- - deterministic and the CNAME that was substituted by the server has no - signature, the resolver may choose a different result than what the - server meant, and consequently end up at the wrong destination. Use - of wildcarded DNAMEs is discouraged in any case [RFC4592]. - - A validating resolver MUST understand DNAME, according to [RFC4034]. - In Section 5.3.3 examples are given that illustrate this need. These - examples are shown with NSEC records, but similar cases exist for - NSEC3. - -8. Acknowledgments - - The authors of this draft would like to acknowledge Matt Larson for - beginning this effort to address the issues related to the DNAME RR - type. - -9. References - -9.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [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. - - - -Rose & Wijngaards Expires February 11, 2008 [Page 14] - -Internet-Draft DNAME Redirection August 2007 - - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name - System", RFC 4592, July 2006. - -9.2. Informative References - - [RFC1912] Barr, D., "Common DNS Operational and Configuration - Errors", RFC 1912, February 1996. - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. - - [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, - April 2006. - -Authors' Addresses - - Scott Rose - NIST - 100 Bureau Dr. - Gaithersburg, MD 20899 - USA - - Phone: +1-301-975-8439 - Fax: +1-301-975-6238 - EMail: scottr@nist.gov - - - Wouter Wijngaards - NLnet Labs - Kruislaan 419 - Amsterdam 1098 VA - The Netherlands - - Phone: +31-20-888-4551 - EMail: wouter@nlnetlabs.nl - - - - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 15] - -Internet-Draft DNAME Redirection August 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - 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, THE IETF TRUST 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). - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 16] - - - - -DNS Extensions Working Group S. Rose -Internet-Draft NIST -Intended status: Standards Track W. Wijngaards -Expires: February 11, 2008 NLnet Labs - August 10, 2007 - - - Update to DNAME Redirection in the DNS - draft-ietf-dnsext-rfc2672bis-dname-04 - -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 February 11, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - The DNAME record provides redirection for a sub-tree of the domain - name tree in the DNS system. That is, all names that end with a - particular suffix are redirected to another part of the DNS. This is - an update to the original specification in RFC 2672. - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 1] - -Internet-Draft DNAME Redirection August 2007 - - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3 - 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4 - 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5 - 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 5 - 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6 - - 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7 - 3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 7 - - 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 9 - - 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 11 - 5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 11 - 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 11 - 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 11 - 5.3.1. DNAME bit in NSEC/NSEC3 type map . . . . . . . . . . . 11 - 5.3.2. Other issues with NSEC3 and DNAME . . . . . . . . . . 12 - 5.3.3. Validators Must Understand DNAME . . . . . . . . . . . 12 - 5.3.3.1. DNAME in Bitmap Causes Invalid Name Error . . . . 12 - 5.3.3.2. Valid Name Error Response Involving DNAME in - Bitmap . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3.3.3. Response With Synthesized CNAME . . . . . . . . . 13 - - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 2] - -Internet-Draft DNAME Redirection August 2007 - - -1. Introduction - - DNAME is a DNS Resource Record type. DNAME provides redirection from - a part of the DNS name tree to another part of the DNS name tree. - - For example, given a query for foo.example.com and a DNAME from - example.com to example.net, the query would be redirected to - foo.example.net. With the same DNAME a query for foo.bar.example.com - would be redirected to foo.bar.example.net. - - The DNAME RR is similar to the CNAME RR in that it provides - redirection. The CNAME RR only provides redirection for exactly one - name while the DNAME RR provides redirection for all names in a sub- - tree of the DNS name tree. - - This document is an update to the original specification of DNAME in - RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of - maintaining address-to-name mappings in a context of network - renumbering. So that with a careful set-up a renumbering event in - the network causes no change to the authoritative server that has the - address-to-name mappings. Examples in practice are classless reverse - address space delegations and punycode alternates for domain spaces. - - Other usage of DNAME lies in redirection of name spaces. For - example, a zone administrator may want subtrees of the DNS to contain - the same information. DNAME is also used for redirection of ENUM - domains to another maintaining party. - - This update to DNAME does not change the wire format or the handling - of DNAME Resource Records by existing software. A new UD (Understand - Dname) bit in the EDNS flags field can be used to signal that CNAME - synthesis is not needed. Discussion is added on problems that may be - encountered when using DNAME. - -2. The DNAME Resource Record - -2.1. Format - - The DNAME RR has mnemonic DNAME and type code 39 (decimal). - - The format of the DNAME record has not changed from the original - specification in RFC 2672. DNAME has the following format: - - DNAME - - The format is not class-sensitive. All fields are required. The - RDATA field target is a domain name. The RDATA field target name - MUST be sent uncompressed [RFC3597]. - - - -Rose & Wijngaards Expires February 11, 2008 [Page 3] - -Internet-Draft DNAME Redirection August 2007 - - - The DNAME RR causes type NS additional section processing. - -2.2. The DNAME Substitution - - DNAMEs cause a name substitution to happen to query names. This is - called the DNAME substitution. The suffix owner name of the DNAME is - replaced by the target of the DNAME. The owner name of the DNAME is - not itself redirected, only domain names below the owner name are - redirected. Only whole labels are replaced. A name is considered - below the owner name if it has more labels than the owner name, and - the labels of the owner name appear as the suffix of the name. See - the table of examples for common cases and corner cases. - - In the table below, the QNAME refers to the query name. The owner is - the DNAME owner domain name, and the target refers to the target of - the DNAME record. The result is the resulting name after performing - the DNAME substitution on the query name. "no match" means that the - query did not match the DNAME and thus no substitution is performed - and a possible error message is returned (if no other result is - possible). In the examples below, 'cyc' and 'shortloop' contain - loops. - - QNAME owner DNAME target result - ---------------- -------------- -------------- ----------------- - com. example.com. example.net. - example.com. example.com. example.net. - a.example.com. example.com. example.net. a.example.net. - a.b.example.com. example.com. example.net. a.b.example.net. - ab.example.com. b.example.com. example.net. - foo.example.com. example.com. example.net. foo.example.net. - a.x.example.com. x.example.com. example.net. a.example.net. - a.example.com. example.com. y.example.net. a.y.example.net. - cyc.example.com. example.com. example.com. cyc.example.com. - cyc.example.com. example.com. c.example.com. cyc.c.example.com. - shortloop.x.x. x. . shortloop.x. - shortloop.x. x. . shortloop. - - Table 1. DNAME Substitution Examples. - - It is possible for DNAMEs to form loops. Just like CNAMEs can form - loops. DNAMEs and CNAMEs can chain together to form loops. A single - corner case DNAME can form a loop. Resolvers and servers should be - cautious in devoting resources to a query, but be aware that fairly - long chains of DNAMEs may be valid. Zone content administrators - should take care to insure that there are no loops that could occur - when using DNAME or DNAME/CNAME redirection. - - The domain name can get too long during substitution. For example, - - - -Rose & Wijngaards Expires February 11, 2008 [Page 4] - -Internet-Draft DNAME Redirection August 2007 - - - suppose the target name of the DNAME RR is 250 octets in length - (multiple labels), if an incoming QNAME that has a first label over 5 - octets in length, the result of the result would be a name over 255 - octets. If this occurs the server returns an RCODE of YXDOMAIN - [RFC2136]. The DNAME record and its signature (if the zone is - signed) are included in the answer as proof for the YXDOMAIN (value - 6) RCODE. - -2.3. DNAME Apex not Redirected itself - - The owner name of a DNAME is not redirected itself. The reason for - the original decision was that one can have a DNAME at the zone apex - without problem. Then use this DNAME at the zone apex to point - queries to the target zone. There still is a need to have the - customary SOA and NS resource records at the zone apex. This means - that DNAME does not mirror a zone completely, as it does not mirror - the zone apex. - - Another reason for excluding the DNAME owner from the DNAME - substitution is that one can then query for the DNAME through RFC - 1034 [RFC1034] caches. - - This means that a DNAME RR is not allowed at the same domain name as - NS records unless there is also a SOA record present. DNAME RRs are - not allowed at the parent side of a delegation point but are allowed - at a zone apex. - -2.4. Names Next to and Below a DNAME Record - - Other resource records MUST NOT exist below the owner of a DNAME RR. - To get the contents for names subordinate to that owner, the DNAME - redirection must be invoked and the resulting target queried. A - server SHOULD refuse to load a zone that has data below a domain name - owning a DNAME RR. Also a server SHOULD refuse to load a zone - subordinate to the owner of a DNAME record in the ancestor zone. - - DNAME is a singleton type, meaning only one DNAME is allowed per - name. The owner name of a DNAME can only have one DNAME RR, and no - CNAME RRs can exist at that name. These rules make sure that for a - single domain name only one redirection exists, and thus no confusion - which one to follow. A server SHOULD refuse to load a zone that - violates these rules. - - The domain name that owns a DNAME record is allowed to have other - resource record types at that domain name, except DNAMEs or CNAMEs. - - These rules allow DNAME records to be queried through DNAME unaware - caches. - - - -Rose & Wijngaards Expires February 11, 2008 [Page 5] - -Internet-Draft DNAME Redirection August 2007 - - -2.5. Compression of the DNAME record. - - The DNAME owner name can be compressed like any other owner name. - The DNAME RDATA target name MUST NOT be sent out in compressed form, - so that a DNAME RR can be treated as an unknown type. - - Although the previous specification [RFC2672] talked about signaling - to allow compression of the target name, no such signaling is - explicitly specified. - - RFC2672 stated that the EDNS version had a meaning for understanding - of DNAME and DNAME target name compression. This document updates - RFC2672, in that there is no EDNS version signaling for DNAME as of - yet. However, the flags section of EDNS(0) is updated with a - Understand-DNAME flag by this document (See Section 3.2). - -3. Processing - -3.1. Wildcards - - The use of DNAME in conjunction with wildcards is discouraged - [RFC4592]. Thus records of the form "*.example.com DNAME - example.net" SHOULD NOT be used. - - The interaction between the expansion of the wildcard and the - redirection of the DNAME is non-deterministic. Because the - processing is non-deterministic, DNSSEC validating resolvers may not - be able to validate a wildcarded DNAME. - - A server MAY give a warning that the behavior is unspecified if such - a wildcarded DNAME is loaded. - -3.2. CNAME synthesis - - On the server side, the DNAME RR record is always included in the - answer section of a query. A CNAME RR record with TTL 0 is - synthesized for old resolvers, specifically for the QNAME in the - query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the - synthesized CNAME does not have to be signed. The DNAME has an RRSIG - and a validating resolver can check the CNAME against the DNAME - record and validate the DNAME record. - - It does not make sense for the authoritative server to follow the - chain of DNAMEs, CNAMEs and wildcards outside of the zone of the - query, as modern resolvers will remove out-of-zone information from - the answer. - - Resolvers MUST be able to handle a synthesized CNAME TTL of zero or - - - -Rose & Wijngaards Expires February 11, 2008 [Page 6] - -Internet-Draft DNAME Redirection August 2007 - - - equal to the TTL of the corresponding DNAME record. The TTL of zero - means that the CNAME can be discarded immediately after processing - the answer. DNSSEC aware resolvers can set the Understand-DNAME (UD - bit) to receive a response with only the DNAME RR and no synthesized - CNAMEs. - - The UD bit is part of the EDNS extended RCODE and Flags field. It is - used to omit server processing, transmission and resolver processing - the unsigned synthesized CNAMEs when DNSSEC validation is performed. - Resolvers can set this in a query to request omission of the - synthesized CNAMEs. Servers copy the UD bit to the response, and can - omit synthesized CNAMEs from the answer. Older resolvers do not set - the UD bit, and older servers do not copy the UD bit to the answer, - and will not omit synthesized CNAMEs. - - Updated EDNS extended RCODE and Flags field. - - +0 (MSB) +1 (LSB) - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 0: | EXTENDED-RCODE | VERSION | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 2: |DO|UD| Z | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - Servers MUST be able to answer a query for a synthesized CNAME. An - answer containing the synthesized CNAME cannot contain an error - (since a CNAME has been followed), as per RFC 1034 CNAME rules. - -3.3. Acceptance and Intermediate Storage - - DNS Caches MUST NOT allow data to be cached below the owner of a - DNAME RR, except CNAME records or perhaps NSEC3 records and their - signatures. CNAME records below the owner of a DNAME MUST be re- - synthesized from the DNAME, or checked against the DNAME record - before sending them out. This improves consistency of the DNAME and - CNAME records below the owner of the DNAME. - - DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant - clients. A DNS Cache that understands DNAMEs can send out queries on - behalf of clients with the UD bit set. After receiving the answers - the DNS Cache sends replies to DNAME ignorant clients that include - DNAMEs and synthesized CNAMEs. - -3.4. Server algorithm - - Below the server algorithm, which appeared in RFC 2672 Section 4.1, - is expanded to handle the UD bit. - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 7] - -Internet-Draft DNAME Redirection August 2007 - - - 1. Set or clear the value of recursion available in the response - depending on whether the name server is willing to provide - recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, otherwise - step 2. - 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. - 3. Start matching down, label by label, in the zone. The matching - process can terminate several ways: - A. If the whole of QNAME is matched, we have found the node. - - If the data at the node is a CNAME, and QTYPE does not match - CNAME, copy the CNAME RR into the answer section of the - response, change QNAME to the canonical name in the CNAME RR, - and go back to step 1. - - Otherwise, copy all RRs which match QTYPE into the answer - section and go to step 6. - B. If a match would take us out of the authoritative data, we - have a referral. This happens when we encounter a node with - NS RRs marking cuts along the bottom of a zone. - - Copy the NS RRs for the subzone into the authority section of - the reply. Put whatever addresses are available into the - additional section, using glue RRs if the addresses are not - available from authoritative data or the cache. Go to step - 4. - C. If at some label, a match is impossible (i.e., the - corresponding label does not exist), look to see whether the - last label matched has a DNAME record. - - If a DNAME record exists at that point, copy that record into - the answer section. If substitution of its for its - in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise - perform the substitution and continue. If the EDNS OPT - record is present in the query and the UD bit is set, the - server MAY copy the UD bit to the answer EDNS OPT record, and - omit CNAME synthesis. Else the server MUST synthesize a - CNAME record as described above and include it in the answer - section. Go back to step 1. - - If there was no DNAME record, look to see if the "*" label - exists. - - If the "*" label does not exist, check whether the name we - are looking for is the original QNAME in the query or a name - - - -Rose & Wijngaards Expires February 11, 2008 [Page 8] - -Internet-Draft DNAME Redirection August 2007 - - - we have followed due to a CNAME or DNAME. 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. If the data at the node with the "*" label 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. Otherwise, Go to step 6. - - 4. Start matching down in the cache. If QNAME is found in the - cache, copy all RRs attached to it that match QTYPE into the - answer section. If QNAME is not found in the cache but a DNAME - record is present at an ancestor of QNAME, copy that DNAME record - into the answer section. If there was no delegation from - authoritative data, look for the best one from the cache, and put - it in the authority section. Go to step 6. - 5. Use the local resolver or a copy of its algorithm to answer the - query. Store the results, including any intermediate CNAMEs and - DNAMEs, in the answer section of the response. - 6. Using local data only, attempt to add other RRs which may be - useful to the additional section of the query. Exit. - - Note that there will be at most one ancestor with a DNAME as - described in step 4 unless some zone's data is in violation of the - no-descendants limitation in section 3. An implementation might take - advantage of this limitation by stopping the search of step 3c or - step 4 when a DNAME record is encountered. - -4. DNAME Discussions in Other Documents - - In [RFC2181], in Section 10.3., the discussion on MX and NS records - touches on redirection by CNAMEs, but this also holds for DNAMEs. - - - - - - - - - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 9] - -Internet-Draft DNAME Redirection August 2007 - - - Excerpt from 10.3. MX and NS records (in RFC 2181). - - The domain name used as the value of a NS resource record, - or part of the value of a MX resource record must not be - an alias. Not only is the specification clear on this - point, but using an alias in either of these positions - neither works as well as might be hoped, nor well fulfills - the ambition that may have led to this approach. This - domain name must have as its value one or more address - records. Currently those will be A records, however in - the future other record types giving addressing - information may be acceptable. It can also have other - RRs, but never a CNAME RR. - - The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. - [RFC3363] does NOT RECOMMENDED the use of DNAME in the IPv6 reverse - tree. (Hence, all references to DNAME should have been removed from - [RFC4294].) Based on the experience gained in the meantime, RFC 3363 - should be revised, dropping all constraints on having DNAME RRs in - these zones. This would greatly improve the manageability of the - IPv6 reverse tree. These changes are made explicit below. - - In [RFC3363], section 4, DNAME is not recommended for the IPv6 - reverse tree. The opening premise of this section is demonstrably - wrong. Everything that follows from that premise is also invalid. - - In [RFC3363], the paragraph - - "The issues for DNAME in the reverse mapping tree appears to be - closely tied to the need to use fragmented A6 in the main tree: if - one is necessary, so is the other, and if one isn't necessary, the - other isn't either. Therefore, in moving RFC 2874 to experimental, - the intent of this document is that use of DNAME RRs in the reverse - tree be deprecated." - - is to be replaced with the word "DELETED". - - In [RFC4294], the reference to DNAME was left in as a editorial - oversight. The paragraph - - "Those nodes are NOT RECOMMENDED to support the experimental A6 and - DNAME Resource Records [RFC3363]." - - - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 10] - -Internet-Draft DNAME Redirection August 2007 - - - is to be replaced by - - "Those nodes are NOT RECOMMENDED to support the experimental - A6 Resource Record [RFC3363]." - -5. Other Issues with DNAME - - There are several issues to be aware of about the use of DNAME. - -5.1. MX, NS and PTR Records Must Point to Target of DNAME - - The names listed as target names of MX, NS and PTR records must be - canonical hostnames. This means no CNAME or DNAME redirection may be - present during DNS lookup of the address records for the host. This - is discussed in RFC 2181 [RFC2181], section 10.3, and RFC 1912 - [RFC1912], section 2.4. - - The upshot of this is that although the lookup of a PTR record can - involve DNAMEs, the name listed in the PTR record can not fall under - a DNAME. The same holds for NS and MX records. For example, when - punycode alternates for a zone use DNAME then the NS, MX and PTR - records that point to that zone must use names without punycode in - their RDATA. What must be done then is to have the domain names with - DNAME substitution already applied to it as the MX, NS, PTR data. - These are valid canonical hostnames. - -5.2. Dynamic Update and DNAME - - Zones containing a DNAME RR MUST NOT accept a dynamic update message - that would add a record or delegation with a name existing under a - DNAME. - - A server MUST return an error message with RCODE=REFUSED [RFC2136] in - response to a dynamic update message that would add a resource record - under a DNAME in the zone. - -5.3. DNSSEC and DNAME - -5.3.1. DNAME bit in NSEC/NSEC3 type map - - When a validator checks the NSEC/NSEC3 RRs returned on a name error - response, it SHOULD check that the DNAME bit is not set. If the - DNAME bit is set then the DNAME substitution should have been done, - but has not. - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 11] - -Internet-Draft DNAME Redirection August 2007 - - -5.3.2. Other issues with NSEC3 and DNAME - - NSEC3 records and their signatures are allowed to exist below the - owner name of a DNAME RR. This is because of the nature of NSEC3 RRs - in DNSSEC, which creates hashed owner names that exist below the apex - name of the zone. This is an exception to the rule that there MUST - NOT be any other RRs under the owner name of a DNAME RR, if the DNAME - RR is owned by the zone apex domain name. - - Queries for NSEC3 owner names are redirected as if there were no such - NSEC3 present. - - There is no significant extra hashing cost for NSEC3 signed zones - when answering queries with DNAME substitution. - -5.3.3. Validators Must Understand DNAME - - Examples of why DNSSEC validators MUST understand DNAME. - -5.3.3.1. DNAME in Bitmap Causes Invalid Name Error - - ;; Header: QR AA DO RCODE=3(NXDOMAIN) - ;; Question - foo.bar.example.com. IN A - ;; Answer - bar.example.com. NSEC dub.example.com. A DNAME - bar.example.com. RRSIG NSEC [valid signature] - - If this is the response, then only by understanding that the DNAME - bit means that foo.bar.example.com needed to have been redirected by - the DNAME, the validator can see that it is a BOGUS reply from an - attacker that collated existing records from the DNS to create a - confusing reply. - - If the DNAME bit had not been set in the NSEC record above then the - answer would have validated as a correct name error response. - -5.3.3.2. Valid Name Error Response Involving DNAME in Bitmap - - - - - - - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 12] - -Internet-Draft DNAME Redirection August 2007 - - - ;; Header: QR AA DO RCODE=3(NXDOMAIN) - ;; Question - cee.example.com. IN A - ;; Answer - bar.example.com. NSEC dub.example.com. A DNAME - bar.example.com. RRSIG NSEC [valid signature] - - If the query had been cee.example.com as shown above, then this - answer would have been validated, because 'cee' does not get - redirected by the DNAME at 'bar'. - -5.3.3.3. Response With Synthesized CNAME - - ;; Header: QR AA DO RCODE=0(NOERROR) - ;; Question - foo.bar.example.com. IN A - ;; Answer - bar.example.com. DNAME bar.example.net. - bar.example.com. RRSIG DNAME [valid signature] - foo.bar.example.com. CNAME foo.bar.example.net. - - The answer shown above has the synthesized CNAME included. However, - the CNAME has no signature, since the server does not sign online (it - is a slow operation and exposes the signing key). So it cannot be - trusted. It could be altered by an attacker to be - foo.bar.example.com CNAME bla.bla.example. The DNAME record does - have its signature included, since it does not change for every query - name. The validator must verify the DNAME signature and then - recursively resolve further to query for the foo.bar.example.net A - record. - -6. IANA Considerations - - The main purpose of this draft is to discuss issues related to the - use of DNAME RRs in a DNS zone. The original document registered the - DNAME Resource Record type code 39 (decimal). IANA should update the - DNS resource record registry by adding a pointer to this document for - RR type 39. - - This draft requests the second highest bit in the EDNS flags field - for the Understand-DNAME (UD) flag. - -7. Security Considerations - - DNAME redirects queries elsewhere, which may impact security based on - policy and the security status of the zone with the DNAME and the - redirection zone's security status. - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 13] - -Internet-Draft DNAME Redirection August 2007 - - - If a validating resolver accepts wildcarded DNAMEs, this creates - security issues. Since the processing of a wildcarded DNAME is non- - deterministic and the CNAME that was substituted by the server has no - signature, the resolver may choose a different result than what the - server meant, and consequently end up at the wrong destination. Use - of wildcarded DNAMEs is discouraged in any case [RFC4592]. - - A validating resolver MUST understand DNAME, according to [RFC4034]. - In Section 5.3.3 examples are given that illustrate this need. These - examples are shown with NSEC records, but similar cases exist for - NSEC3. - -8. Acknowledgments - - The authors of this draft would like to acknowledge Matt Larson for - beginning this effort to address the issues related to the DNAME RR - type. - -9. References - -9.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [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. - - - -Rose & Wijngaards Expires February 11, 2008 [Page 14] - -Internet-Draft DNAME Redirection August 2007 - - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name - System", RFC 4592, July 2006. - -9.2. Informative References - - [RFC1912] Barr, D., "Common DNS Operational and Configuration - Errors", RFC 1912, February 1996. - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. - - [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, - April 2006. - -Authors' Addresses - - Scott Rose - NIST - 100 Bureau Dr. - Gaithersburg, MD 20899 - USA - - Phone: +1-301-975-8439 - Fax: +1-301-975-6238 - EMail: scottr@nist.gov - - - Wouter Wijngaards - NLnet Labs - Kruislaan 419 - Amsterdam 1098 VA - The Netherlands - - Phone: +31-20-888-4551 - EMail: wouter@nlnetlabs.nl - - - - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 15] - -Internet-Draft DNAME Redirection August 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - 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, THE IETF TRUST 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). - - - - - - - -Rose & Wijngaards Expires February 11, 2008 [Page 16] - diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-06.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-06.txt new file mode 100644 index 0000000000..a77e42399a --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-06.txt @@ -0,0 +1,896 @@ + + + +DNS Extensions Working Group S. Rose +Internet-Draft NIST +Intended status: Standards Track W. Wijngaards +Expires: May 17, 2008 NLnet Labs + November 14, 2007 + + + Update to DNAME Redirection in the DNS + draft-ietf-dnsext-rfc2672bis-dname-06 + +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 May 17, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + The DNAME record provides redirection for a sub-tree of the domain + name tree in the DNS system. That is, all names that end with a + particular suffix are redirected to another part of the DNS. This is + an update to the original specification in RFC 2672. + + + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 1] + +Internet-Draft DNAME Redirection November 2007 + + +Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + + 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3 + 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4 + 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5 + 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 5 + 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6 + + 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7 + 3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 + + 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 10 + + 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 11 + 5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 11 + 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 11 + 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 11 + 5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 11 + 5.3.2. Validators Must Understand DNAME . . . . . . . . . . . 12 + 5.3.2.1. DNAME in Bitmap Causes Invalid Name Error . . . . 12 + 5.3.2.2. Valid Name Error Response Involving DNAME in + Bitmap . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3.2.3. Response With Synthesized CNAME . . . . . . . . . 12 + + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 + + + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 2] + +Internet-Draft DNAME Redirection November 2007 + + +1. Introduction + + DNAME is a DNS Resource Record type. DNAME provides redirection from + a part of the DNS name tree to another part of the DNS name tree. + + Take for example, looking through a zone (see RFC 1034 [RFC1034], + section 4.3.2, step 3) for the domain name "foo.example.com" and a + DNAME resource record is found at "example.com" indicating that all + queries under "example.com" be directed to "example.net". The lookup + process will return to step 1 with the new query name of + "foo.example.net". Had the query name been "www.foo.example.com" the + new query name would be "www.foo.example.net". + + The DNAME RR is similar to the CNAME RR in that it provides + redirection. The CNAME RR only provides redirection for exactly one + name while the DNAME RR provides redirection for all names in a sub- + tree of the DNS name tree. + + This document is an update to the original specification of DNAME in + RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of + maintaining address-to-name mappings in a context of network + renumbering. With a careful set-up, a renumbering event in the + network causes no change to the authoritative server that has the + address-to-name mappings. Examples in practice are classless reverse + address space delegations and punycode alternates for domain spaces. + + Another usage of DNAME lies in redirection of name spaces. For + example, a zone administrator may want sub-trees of the DNS to + contain the same information. DNAME is also used for redirection of + ENUM domains to another maintaining party. + + This update to DNAME does not change the wire format or the handling + of DNAME Resource Records by existing software. A new UD (Understand + Dname) bit in the EDNS flags field can be used to signal that CNAME + synthesis is not needed. Discussion is added on problems that may be + encountered when using DNAME. + +2. The DNAME Resource Record + +2.1. Format + + The DNAME RR has mnemonic DNAME and type code 39 (decimal). + + + + + + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 3] + +Internet-Draft DNAME Redirection November 2007 + + + The format of the DNAME record has not changed from the original + specification in RFC 2672. DNAME has the following format: + + DNAME + + The format is not class-sensitive. All fields are required. The + RDATA field target is a domain name. The RDATA field target name + MUST be sent uncompressed [RFC3597]. + + The DNAME RR causes type NS additional section processing. + +2.2. The DNAME Substitution + + DNAMEs cause a name substitution to happen to query names. This is + called the DNAME substitution. The portion of the QNAME ending with + the root label that matches the owner name of the DNAME RR is + replaced with the contents of the DNAME RR's RDATA. The owner name + of the DNAME is not itself redirected, only domain names below the + owner name are redirected. Only whole labels are replaced. A name + is considered below the owner name if it has more labels than the + owner name, and the labels of the owner name appear at the end of the + query name. See the table of examples for common cases and corner + cases. + + In the table below, the QNAME refers to the query name. The owner is + the DNAME owner domain name, and the target refers to the target of + the DNAME record. The result is the resulting name after performing + the DNAME substitution on the query name. "no match" means that the + query did not match the DNAME and thus no substitution is performed + and a possible error message is returned (if no other result is + possible). In the examples below, 'cyc' and 'shortloop' contain + loops. + + QNAME owner DNAME target result + ---------------- -------------- -------------- ----------------- + com. example.com. example.net. + example.com. example.com. example.net. + a.example.com. example.com. example.net. a.example.net. + a.b.example.com. example.com. example.net. a.b.example.net. + ab.example.com. b.example.com. example.net. + foo.example.com. example.com. example.net. foo.example.net. + a.x.example.com. x.example.com. example.net. a.example.net. + a.example.com. example.com. y.example.net. a.y.example.net. + cyc.example.com. example.com. example.com. cyc.example.com. + cyc.example.com. example.com. c.example.com. cyc.c.example.com. + shortloop.x.x. x. . shortloop.x. + shortloop.x. x. . shortloop. + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 4] + +Internet-Draft DNAME Redirection November 2007 + + + Table 1. DNAME Substitution Examples. + + It is possible for DNAMEs to form loops, just as CNAMEs can form + loops. DNAMEs and CNAMEs can chain together to form loops. A single + corner case DNAME can form a loop. Resolvers and servers should be + cautious in devoting resources to a query, but be aware that fairly + long chains of DNAMEs may be valid. Zone content administrators + should take care to insure that there are no loops that could occur + when using DNAME or DNAME/CNAME redirection. + + The domain name can get too long during substitution. For example, + suppose the target name of the DNAME RR is 250 octets in length + (multiple labels), if an incoming QNAME that has a first label over 5 + octets in length, the result of the result would be a name over 255 + octets. If this occurs the server returns an RCODE of YXDOMAIN + [RFC2136]. The DNAME record and its signature (if the zone is + signed) are included in the answer as proof for the YXDOMAIN (value + 6) RCODE. + +2.3. DNAME Apex not Redirected itself + + The owner name of a DNAME is not redirected itself. The reason for + the original decision was that one can have a DNAME at the zone apex + without problem. Then use this DNAME at the zone apex to point + queries to the target zone. There still is a need to have the + customary SOA and NS resource records at the zone apex. This means + that DNAME does not mirror a zone completely, as it does not mirror + the zone apex. + + Another reason for excluding the DNAME owner from the DNAME + substitution is that one can then query for the DNAME through RFC + 1034 [RFC1034] caches. + + This means that a DNAME RR is not allowed at the same domain name as + NS records unless there is also a SOA record present. DNAME RRs are + not allowed at the parent side of a delegation point but are allowed + at a zone apex. + +2.4. Names Next to and Below a DNAME Record + + Other resource records MUST NOT exist below the owner of a DNAME RR. + To get the contents for names subordinate to that owner, the DNAME + redirection must be invoked and the resulting target queried. A + server SHOULD refuse to load a zone that has data below a domain name + owning a DNAME RR. Also a server SHOULD refuse to load a zone + subordinate to the owner of a DNAME record in the ancestor zone. See + Section 5.2 for further restrictions related to dynamic update. + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 5] + +Internet-Draft DNAME Redirection November 2007 + + + DNAME is a singleton type, meaning only one DNAME is allowed per + name. The owner name of a DNAME can only have one DNAME RR, and no + CNAME RRs can exist at that name. These rules make sure that for a + single domain name only one redirection exists, and thus no confusion + which one to follow. A server SHOULD refuse to load a zone that + violates these rules. + + The domain name that owns a DNAME record is allowed to have other + resource record types at that domain name, except DNAMEs or CNAMEs. + + These rules allow DNAME records to be queried through DNAME unaware + caches. + +2.5. Compression of the DNAME record. + + The DNAME owner name can be compressed like any other owner name. + The DNAME RDATA target name MUST NOT be sent out in compressed form, + so that a DNAME RR can be treated as an unknown type. + + Although the previous specification [RFC2672] talked about signaling + to allow compression of the target name, no such signaling is + explicitly specified. + + RFC2672 stated that the EDNS version had a meaning for understanding + of DNAME and DNAME target name compression. This document updates + RFC2672, in that there is no EDNS version signaling for DNAME as of + yet. However, the flags section of EDNS(0) is updated with a + Understand-DNAME flag by this document (See Section 3.2). + +3. Processing + +3.1. Wildcards + + The use of DNAME in conjunction with wildcards is discouraged + [RFC4592]. Thus records of the form "*.example.com DNAME + example.net" SHOULD NOT be used. + + The interaction between the expansion of the wildcard and the + redirection of the DNAME is non-deterministic. Because the + processing is non-deterministic, DNSSEC validating resolvers may not + be able to validate a wildcarded DNAME. + + A server MAY give a warning that the behavior is unspecified if such + a wildcarded DNAME is loaded. The server MAY refuse it, refuse to + load or refuse dynamic update. + + + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 6] + +Internet-Draft DNAME Redirection November 2007 + + +3.2. CNAME synthesis + + On the server side, the DNAME RR record is always included in the + answer section of a query, when one is encountered. A CNAME RR + record with TTL equal to the corresponding DNAME RR is synthesized + for old resolvers, specifically for the QNAME in the query. DNSSEC + [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does + not have to be signed. The DNAME has an RRSIG and a validating + resolver can check the CNAME against the DNAME record and validate + the DNAME record. + + It does not make sense for the authoritative server to follow the + chain of DNAMEs, CNAMEs and wildcards outside of the zone of the + query, as some resolver implementations will remove out-of-zone + information from the answer. + + Resolvers MUST be able to handle a synthesized CNAME TTL of zero or + equal to the TTL of the corresponding DNAME record. The TTL of zero + means that the CNAME can be discarded immediately after processing + the answer. DNAME aware resolvers can set the Understand-DNAME (UD + bit) to receive a response with only the DNAME RR and no synthesized + CNAMEs. + + The UD bit is part of the EDNS extended RCODE and Flags field. It is + used to omit server processing, transmission and resolver processing + of unsigned synthesized CNAMEs. Resolvers can set this in a query to + request omission of the synthesized CNAMEs. Servers copy the UD bit + to the response, and can omit synthesized CNAMEs from the answer. + Older resolvers do not set the UD bit, and older servers do not copy + the UD bit to the answer, and will not omit synthesized CNAMEs. + + Updated EDNS extended RCODE and Flags field. + + +0 (MSB) +1 (LSB) + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 0: | EXTENDED-RCODE | VERSION | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 2: |DO|UD| Z | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Servers MUST be able to answer a query for a synthesized CNAME. An + answer containing the synthesized CNAME cannot contain an error + (since a CNAME has been followed), as per RFC 1034 CNAME rules. + +3.3. Acceptance and Intermediate Storage + + DNS Caches MUST NOT allow data to be cached below the owner of a + DNAME RR, except CNAME records and their signatures. CNAME records + + + +Rose & Wijngaards Expires May 17, 2008 [Page 7] + +Internet-Draft DNAME Redirection November 2007 + + + below the owner of a DNAME MUST be re-synthesized from the DNAME, or + checked against the DNAME record before sending them out. This + improves consistency of the DNAME and CNAME records below the owner + of the DNAME. + + DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant + clients. A DNS Cache that understands DNAMEs can send out queries on + behalf of clients with the UD bit set. After receiving the answers + the DNS Cache sends replies to DNAME ignorant clients that include + DNAMEs and synthesized CNAMEs. + +3.4. Server algorithm + + Below the server algorithm, which appeared in RFC 2672 Section 4.1, + is expanded to handle the UD bit. + + 1. Set or clear the value of recursion available in the response + depending on whether the name server is willing to provide + recursive service. If recursive service is available and + requested via the RD bit in the query, go to step 5, otherwise + step 2. + + 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. + + 3. Start matching down, label by label, in the zone. The matching + process can terminate several ways: + + A. If the whole of QNAME is matched, we have found the node. + + If the data at the node is a CNAME, and QTYPE does not match + CNAME, copy the CNAME RR into the answer section of the + response, change QNAME to the canonical name in the CNAME RR, + and go back to step 1. + + Otherwise, copy all RRs which match QTYPE into the answer + section and go to step 6. + + B. If a match would take us out of the authoritative data, we + have a referral. This happens when we encounter a node with + NS RRs marking cuts along the bottom of a zone. + + Copy the NS RRs for the sub-zone into the authority section + of the reply. Put whatever addresses are available into the + additional section, using glue RRs if the addresses are not + available from authoritative data or the cache. Go to step + 4. + + + +Rose & Wijngaards Expires May 17, 2008 [Page 8] + +Internet-Draft DNAME Redirection November 2007 + + + C. If at some label, a match is impossible (i.e., the + corresponding label does not exist), look to see whether the + last label matched has a DNAME record. + + If a DNAME record exists at that point, copy that record into + the answer section. If substitution of its for its + in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise + perform the substitution and continue. If the EDNS OPT + record is present in the query and the UD bit is set, the + server MAY copy the UD bit to the answer EDNS OPT record, and + omit CNAME synthesis. Else the server MUST synthesize a + CNAME record as described above and include it in the answer + section. Go back to step 1. + + If there was no DNAME record, look to see if the "*" label + exists. + + 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 or DNAME. 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. If the data at the node with the "*" label 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. Otherwise, Go to step 6. + + 4. Start matching down in the cache. If QNAME is found in the + cache, copy all RRs attached to it that match QTYPE into the + answer section. If QNAME is not found in the cache but a DNAME + record is present at an ancestor of QNAME, copy that DNAME record + into the answer section. If there was no delegation from + authoritative data, look for the best one from the cache, and put + it in the authority section. Go to step 6. + + 5. Use the local resolver or a copy of its algorithm to answer the + query. Store the results, including any intermediate CNAMEs and + DNAMEs, in the answer section of the response. + + 6. Using local data only, attempt to add other RRs which may be + useful to the additional section of the query. Exit. + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 9] + +Internet-Draft DNAME Redirection November 2007 + + + Note that there will be at most one ancestor with a DNAME as + described in step 4 unless some zone's data is in violation of the + no-descendants limitation in section 3. An implementation might take + advantage of this limitation by stopping the search of step 3c or + step 4 when a DNAME record is encountered. + +4. DNAME Discussions in Other Documents + + In [RFC2181], in Section 10.3., the discussion on MX and NS records + touches on redirection by CNAMEs, but this also holds for DNAMEs. + + Excerpt from 10.3. MX and NS records (in RFC 2181). + + The domain name used as the value of a NS resource record, + or part of the value of a MX resource record must not be + an alias. Not only is the specification clear on this + point, but using an alias in either of these positions + neither works as well as might be hoped, nor well fulfills + the ambition that may have led to this approach. This + domain name must have as its value one or more address + records. Currently those will be A records, however in + the future other record types giving addressing + information may be acceptable. It can also have other + RRs, but never a CNAME RR. + + The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. + [RFC3363] does NOT RECOMMENDED the use of DNAME in the IPv6 reverse + tree. (Hence, all references to DNAME should have been removed from + [RFC4294].) Based on the experience gained in the meantime, RFC 3363 + should be revised, dropping all constraints on having DNAME RRs in + these zones. This would greatly improve the manageability of the + IPv6 reverse tree. These changes are made explicit below. + + In [RFC3363], section 4, DNAME is not recommended for the IPv6 + reverse tree. The opening premise of this section is demonstrably + wrong. Everything that follows from that premise is also invalid. + + In [RFC3363], the paragraph + + "The issues for DNAME in the reverse mapping tree appears to be + closely tied to the need to use fragmented A6 in the main tree: if + one is necessary, so is the other, and if one isn't necessary, the + other isn't either. Therefore, in moving RFC 2874 to experimental, + the intent of this document is that use of DNAME RRs in the reverse + tree be deprecated." + + is to be replaced with the word "DELETED". + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 10] + +Internet-Draft DNAME Redirection November 2007 + + + In [RFC4294], the reference to DNAME was left in as a editorial + oversight. The paragraph + + "Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC3363]." + + is to be replaced by + + "Those nodes are NOT RECOMMENDED to support the experimental + A6 Resource Record [RFC3363]." + +5. Other Issues with DNAME + + There are several issues to be aware of about the use of DNAME. + +5.1. MX, NS and PTR Records Must Point to Target of DNAME + + The names listed as target names of MX, NS and PTR records must be + canonical hostnames. This means no CNAME or DNAME redirection may be + present during DNS lookup of the address records for the host. This + is discussed in RFC 2181 [RFC2181], section 10.3, and RFC 1912 + [RFC1912], section 2.4. + + The upshot of this is that although the lookup of a PTR record can + involve DNAMEs, the name listed in the PTR record can not fall under + a DNAME. The same holds for NS and MX records. For example, when + punycode alternates for a zone use DNAME then the NS, MX and PTR + records that point to that zone must use names without punycode in + their RDATA. What must be done then is to have the domain names with + DNAME substitution already applied to it as the MX, NS, PTR data. + These are valid canonical hostnames. + +5.2. Dynamic Update and DNAME + + Zones containing a DNAME RR MUST NOT accept a dynamic update message + that would add a record or delegation with a name existing under a + DNAME. + + A server MUST return an error message with RCODE=REFUSED [RFC2136] in + response to a dynamic update message that would add a resource record + under a DNAME in the zone. + +5.3. DNSSEC and DNAME + +5.3.1. DNAME bit in NSEC type map + + When a validator checks the NSEC RRs returned on a name error + response, it SHOULD check that the DNAME bit is not set. If the + + + +Rose & Wijngaards Expires May 17, 2008 [Page 11] + +Internet-Draft DNAME Redirection November 2007 + + + DNAME bit is set then the DNAME substitution should have been done, + but has not. + +5.3.2. Validators Must Understand DNAME + + Examples of why DNSSEC validators MUST understand DNAME. + +5.3.2.1. DNAME in Bitmap Causes Invalid Name Error + + ;; Header: QR AA DO RCODE=3(NXDOMAIN) + ;; Question + foo.bar.example.com. IN A + ;; Answer + bar.example.com. NSEC dub.example.com. A DNAME + bar.example.com. RRSIG NSEC [valid signature] + + If this is the response, then only by understanding that the DNAME + bit means that foo.bar.example.com needed to have been redirected by + the DNAME, the validator can see that it is a BOGUS reply from an + attacker that collated existing records from the DNS to create a + confusing reply. + + If the DNAME bit had not been set in the NSEC record above then the + answer would have validated as a correct name error response. + +5.3.2.2. Valid Name Error Response Involving DNAME in Bitmap + + ;; Header: QR AA DO RCODE=3(NXDOMAIN) + ;; Question + cee.example.com. IN A + ;; Answer + bar.example.com. NSEC dub.example.com. A DNAME + bar.example.com. RRSIG NSEC [valid signature] + + This reply has the same NSEC records as the example above, but with + this query name (cee.example.com), the answer is validated, because + 'cee' does not get redirected by the DNAME at 'bar'. + +5.3.2.3. Response With Synthesized CNAME + + + + + + + + + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 12] + +Internet-Draft DNAME Redirection November 2007 + + + ;; Header: QR AA DO RCODE=0(NOERROR) + ;; Question + foo.bar.example.com. IN A + ;; Answer + bar.example.com. DNAME bar.example.net. + bar.example.com. RRSIG DNAME [valid signature] + foo.bar.example.com. CNAME foo.bar.example.net. + + The answer shown above has the synthesized CNAME included. However, + the CNAME has no signature, since the server does not sign online (it + is a slow operation and exposes the signing key). So it cannot be + trusted. It could be altered by an attacker to be + foo.bar.example.com CNAME bla.bla.example. The DNAME record does + have its signature included, since it does not change for every query + name. The validator must verify the DNAME signature and then + recursively resolve further to query for the foo.bar.example.net A + record. + +6. IANA Considerations + + The main purpose of this draft is to discuss issues related to the + use of DNAME RRs in a DNS zone. The original document registered the + DNAME Resource Record type code 39 (decimal). IANA should update the + DNS resource record registry by adding a pointer to this document for + RR type 39. + + This draft requests the second highest bit in the EDNS flags field + for the Understand-DNAME (UD) flag. + +7. Security Considerations + + DNAME redirects queries elsewhere, which may impact security based on + policy and the security status of the zone with the DNAME and the + redirection zone's security status. + + If a validating resolver accepts wildcarded DNAMEs, this creates + security issues. Since the processing of a wildcarded DNAME is non- + deterministic and the CNAME that was substituted by the server has no + signature, the resolver may choose a different result than what the + server meant, and consequently end up at the wrong destination. Use + of wildcarded DNAMEs is discouraged in any case [RFC4592]. + + A validating resolver MUST understand DNAME, according to [RFC4034]. + In Section 5.3.2 examples are given that illustrate this need. + + + + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 13] + +Internet-Draft DNAME Redirection November 2007 + + +8. Acknowledgments + + The authors of this draft would like to acknowledge Matt Larson for + beginning this effort to address the issues related to the DNAME RR + type. + +9. References + +9.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", + RFC 2672, August 1999. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [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. + + [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name + System", RFC 4592, July 2006. + +9.2. Informative References + + [RFC1912] Barr, D., "Common DNS Operational and Configuration + Errors", RFC 1912, February 1996. + + + +Rose & Wijngaards Expires May 17, 2008 [Page 14] + +Internet-Draft DNAME Redirection November 2007 + + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, + April 2006. + +Authors' Addresses + + Scott Rose + NIST + 100 Bureau Dr. + Gaithersburg, MD 20899 + USA + + Phone: +1-301-975-8439 + Fax: +1-301-975-6238 + EMail: scottr@nist.gov + + + Wouter Wijngaards + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + Phone: +31-20-888-4551 + EMail: wouter@nlnetlabs.nl + + + + + + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 15] + +Internet-Draft DNAME Redirection November 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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). + + + + + + + +Rose & Wijngaards Expires May 17, 2008 [Page 16] + diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-01.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-01.txt deleted file mode 100644 index 652b287aa4..0000000000 --- a/doc/draft/draft-ietf-dnsop-default-local-zones-01.txt +++ /dev/null @@ -1,561 +0,0 @@ - - - -Network Working Group M. Andrews -Internet-Draft ISC -Intended status: Best Current March 2, 2007 -Practice -Expires: September 3, 2007 - - - Locally-served DNS Zones - draft-ietf-dnsop-default-local-zones-01 - -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 September 3, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - Practice has shown that there are a number of DNS zones all iterative - resolvers and recursive nameservers should, unless configured - otherwise, automatically serve. RFC 4193 already specifies that this - should occur for D.F.IP6.ARPA. This document extends the practice to - cover the IN-ADDR.ARPA zones for RFC 1918 address space and other - well known zones with similar usage constraints. - - - - -Andrews Expires September 3, 2007 [Page 1] - -Internet-Draft Locally-served DNS Zones March 2007 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 3 - 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4 - 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5 - 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 5 - 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6 - 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6 - 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 6 - 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 6 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 - Appendix A. Change History [To Be Removed on Publication] . . . . 9 - A.1. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 9 - A.2. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 9 - A.3. draft-andrews-full-service-resolvers-03.txt . . . . . . . 9 - A.4. draft-andrews-full-service-resolvers-02.txt . . . . . . . 9 - Appendix B. Proposed Status [To Be Removed on Publication] . . . 9 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 - Intellectual Property and Copyright Statements . . . . . . . . . . 10 - - - - - - - - - - - - - - - - - - - - - - - - -Andrews Expires September 3, 2007 [Page 2] - -Internet-Draft Locally-served DNS Zones March 2007 - - -1. Introduction - - Practice has shown that there are a number of DNS [RFC 1034] [RFC - 1035] zones all iterative resolvers and recursive nameservers should, - unless configured otherwise, automatically serve. These zones - include, but are not limited to, the IN-ADDR.ARPA zones for the - address space allocated by [RFC 1918] and the IP6.ARPA zones for - locally assigned local IPv6 addresses, [RFC 4193]. - - This recommendation is made because data has shown that significant - leakage of queries for these name spaces is occurring, despite - instructions to restrict them, and because sacrificial name servers - have been deployed to protect the immediate parent name servers for - these zones from excessive, unintentional, query load [AS112]. There - is every expectation that the query load will continue to increase - unless steps are taken as outlined here. - - Additionally, queries from clients behind badly configured firewalls - that allow outgoing queries but drop responses for these name spaces - also puts a significant load on the root servers. They also cause - operational load for the root server operators as they have to reply - to queries about why the root servers are "attacking" these clients. - Changing the default configuration will address all these issues for - the zones listed below in Section 4. - - [RFC 4193] already recommends that queries for D.F.IP6.ARPA be - handled locally. This document extends the recommendation to cover - the IN-ADDR.ARPA zones for [RFC 1918] and other well known IN- - ADDR.ARPA and IP6.ARPA zones for which queries should not appear on - the public Internet. - - It is hoped that by doing this the number of sacrificial servers - [AS112] will not have to be increased and may in time be reduced. - - It should also help DNS responsiveness for sites which are using [RFC - 1918] addresses but do not follow the last paragraph in section 3 of - [RFC 1918]. - -1.1. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - -2. Effects on sites using RFC 1918 addresses. - - For most sites using [RFC 1918] addresses, the changes here will have - - - -Andrews Expires September 3, 2007 [Page 3] - -Internet-Draft Locally-served DNS Zones March 2007 - - - little or no detrimental effect. If the site does not already have - the reverse tree populated the only effect will be that the answers - are generated locally rather than remotely. - - For sites that do have the reverse tree populated, most will either - have a local copy of the zones or will be forwarding the queries to - servers which have local copies of the zone. In either case the - local resolver has a pre-existing configuration for the namespace and - won't add the automatic zone. - - The main impact will be felt at sites that make use of delegation for - reverse lookups for [RFC 1918] addresses and have populated these - zones. Typically, such sites will be fully disconnected from the - Internet and have their own root servers for their own non-Internet - DNS tree. These sites will need to override the default - configuration expressed in this document to allow resolution to - continue. - - -3. Changes to Iterative Resolver Behaviour. - - Unless configured otherwise, an iterative resolver will now return - name errors (RCODE=3) for queries within the lists of zones covered - below, with the obvious exception of queries for the zone name itself - where SOA, NS and "no data" responses will be returned as appropriate - to the query type. One common way to do this is to serve empty (SOA - and NS only) zones. - - A implementation doing this MUST provide a mechanism to disable this - new behaviour, preferably on a zone by zone basis. - - If using empty zones one SHOULD NOT use the same NS and SOA records - as used on the public Internet servers as that will make it harder to - detect leakage to the public Internet servers. This document - recommends that the NS record defaults to the name of the zone and - the SOA MNAME defaults to the name of the only NS RR's target. The - SOA RNAME should default to ".". Implementations SHOULD provide a - mechanism to set these values. No address records need to be - provided for the name server. - - Below is a example of a generic empty zone in master file format. It - will produce a negative cache ttl of 3 hours. - - @ 10800 IN SOA @ . 1 3600 1200 604800 10800 - @ 10800 IN NS @ - - The SOA RR is needed to support negative caching [RFC 2308] of name - error responses and to point clients to the primary master for DNS - - - -Andrews Expires September 3, 2007 [Page 4] - -Internet-Draft Locally-served DNS Zones March 2007 - - - dynamic updates. - - SOA values of particular importance are the MNAME, the SOA RR's TTL - and the negTTL value. Both TTL values SHOULD match. The rest of the - SOA timer values may be chosen arbitrarily since it they are not - intended to control any zone transfer activity. - - The NS RR is needed as some UPDATE clients use NS queries to discover - they zone to be updated. Having no address records for the name - server should abort UPDATE processing in the client - - -4. Lists Of Zones Covered - - The lists below are expected to seed a IANA registry. - -4.1. RFC 1918 Zones - - 10.IN-ADDR.ARPA - 16.172.IN-ADDR.ARPA - 17.172.IN-ADDR.ARPA - 18.172.IN-ADDR.ARPA - 19.172.IN-ADDR.ARPA - 20.172.IN-ADDR.ARPA - 21.172.IN-ADDR.ARPA - 22.172.IN-ADDR.ARPA - 23.172.IN-ADDR.ARPA - 24.172.IN-ADDR.ARPA - 25.172.IN-ADDR.ARPA - 26.172.IN-ADDR.ARPA - 27.172.IN-ADDR.ARPA - 28.172.IN-ADDR.ARPA - 29.172.IN-ADDR.ARPA - 30.172.IN-ADDR.ARPA - 31.172.IN-ADDR.ARPA - 168.192.IN-ADDR.ARPA - -4.2. RFC 3330 Zones - - See [RFC 3330]. - - 0.IN-ADDR.ARPA /* IPv4 "THIS" NETWORK */ - 127.IN-ADDR.ARPA /* IPv4 LOOP-BACK NETWORK */ - 254.169.IN-ADDR.ARPA /* IPv4 LINK LOCAL */ - 2.0.192.IN-ADDR.ARPA /* IPv4 TEST NET */ - 255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */ - - - - - -Andrews Expires September 3, 2007 [Page 5] - -Internet-Draft Locally-served DNS Zones March 2007 - - -4.3. Local IPv6 Unicast Addresses - - See [RFC 4291], sections 2.4, 2.5.2 and 2.5.3. - - 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP - 6.ARPA - 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP - 6.ARPA - -4.4. IPv6 Locally Assigned Local Addresses - - See [RFC 4193]. - - D.F.IP6.ARPA - -4.5. IPv6 Link Local Addresses - - See [RFC 4291], sections 2.4 and 2.5.6. - - 8.E.F.IP6.ARPA - 9.E.F.IP6.ARPA - A.E.F.IP6.ARPA - B.E.F.IP6.ARPA - - -5. Zones that are Out-Of-Scope - - IPv6 site-local addresses, [RFC 4291] sections 2.4 and 2.57, and IPv6 - Globally Assigned Local [RFC 4193] addresses are not covered here. - It is expected that IPv6 site-local addresses will be self correcting - as IPv6 implementations remove support for site-local addresses. - However, sacrificial servers for C.E.F.IP6.ARPA to F.E.F.IP6.ARPA may - still need to be deployed in the short term if the traffic becomes - excessive. - - For IPv6 Globally Assigned Local addresses [RFC 4291] there has been - no decision made about whether the registries will provide - delegations in this space or not. If they don't, then C.F.IP6.ARPA - will need to be added to the list above. If they do, then registries - will need to take steps to ensure that name servers are provided for - these addresses. - - This document is also ignoring IP6.INT. IP6.INT has been wound up - with only legacy resolvers now generating reverse queries under - IP6.INT. - - This document has also deliberately ignored names immediately under - the root. While there is a subset of queries to the roots which - - - -Andrews Expires September 3, 2007 [Page 6] - -Internet-Draft Locally-served DNS Zones March 2007 - - - could be addressed using the techniques described here (e.g. .local - and IPv4 addresses) there is also a vast amount of traffic that - requires a different strategy (e.g. lookups for unqualied hostnames, - IPv6 addresses). - - -6. IANA Considerations - - This document recommends that IANA establish a registry of zones - which require this default behaviour, the initial contents of which - are in Section 4. More zones are expected to be added, and possibly - deleted from this registry over time. Name server implementors are - encouraged to check this registry and adjust their implementations to - reflect changes therein. - - This registry can be amended through "IETF Consensus" as per [RFC - 2434] or IETF Review in 2434bis. - - IANA should co-ordinate with the RIRs and ICANN to ensure the DNSSEC - deployment in the reverse trees that these zone are delegated in a - unsecure manner as per Security Considerations. - - -7. Security Considerations - - During the initial deployment phase, particularly where [RFC 1918] - addresses are in use, there may be some clients that unexpectedly - receive a name error rather than a PTR record. This may cause some - service disruption until full service resolvers have been re- - configured. - - When DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA - namespaces, the zones listed above will need to be delegated as - insecure delegations. This will allow DNSSEC validation to succeed - for queries in these spaces despite not being answered from the - delegated servers. - - It is recommended that sites actively using these namespaces secure - them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust - anchors. This will protect the clients from accidental leakage of - unsigned answers from the Internet. - - -8. Acknowledgements - - This work was supported by the US National Science Foundation - (research grant SCI-0427144) and DNS-OARC. - - - - -Andrews Expires September 3, 2007 [Page 7] - -Internet-Draft Locally-served DNS Zones March 2007 - - -9. References - -9.1. Normative References - - [RFC 1034] - Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", - RFC 1034, STD 13, November 1987. - - [RFC 1035] - Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND - SPECIFICATION", RFC 1035, STD 13, November 1987. - - [RFC 1918] - Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., - and E. Lear, "Address Allocation for Private Internets", - RFC 1918, February 1996. - - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2308] - Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2398, March 1998. - - [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC 3330] - "Special-Use IPv4 Addresses", RFC 3330, September 2002. - - [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC 4291] - Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - -9.2. Informative References - - [AS112] "AS112 Project", . - - [RFC 4193] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - - - -Andrews Expires September 3, 2007 [Page 8] - -Internet-Draft Locally-served DNS Zones March 2007 - - - Addresses", RFC 4193, October 2005. - - -Appendix A. Change History [To Be Removed on Publication] - -A.1. draft-ietf-dnsop-default-local-zones-01.txt - - Revised impact description. - - Updated to reflect change in IP6.INT status. - -A.2. draft-ietf-dnsop-default-local-zones-00.txt - - Adopted by DNSOP. - - "Author's Note" re-titled "Zones that are Out-Of-Scope" - - Add note that these zone are expected to seed the IANA registry. - - Title changed. - -A.3. draft-andrews-full-service-resolvers-03.txt - - Added "Proposed Status". - -A.4. draft-andrews-full-service-resolvers-02.txt - - Added 0.IN-ADDR.ARPA. - - -Appendix B. Proposed Status [To Be Removed on Publication] - - This Internet-Draft is being submitted for eventual publication as an - RFC with a proposed status of Best Current Practice. - - -Author's Address - - Mark P. Andrews - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - US - - Email: Mark_Andrews@isc.org - - - - - - -Andrews Expires September 3, 2007 [Page 9] - -Internet-Draft Locally-served DNS Zones March 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - 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, THE IETF TRUST 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. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Andrews Expires September 3, 2007 [Page 10] - - diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-03.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-03.txt new file mode 100644 index 0000000000..5d47673ccb --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-default-local-zones-03.txt @@ -0,0 +1,672 @@ + + + +Network Working Group M. Andrews +Internet-Draft ISC +Intended status: Best Current November 19, 2007 +Practice +Expires: May 22, 2008 + + + Locally-served DNS Zones + draft-ietf-dnsop-default-local-zones-03 + +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 May 22, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + Experience has shown that there are a number of DNS zones all + iterative resolvers and recursive nameservers should, unless + configured otherwise, automatically serve. RFC 4193 specifies that + this should occur for D.F.IP6.ARPA. This document extends the + practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space + and other well known zones with similar characteristics. + + + + +Andrews Expires May 22, 2008 [Page 1] + +Internet-Draft Locally-served DNS Zones November 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4 + 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4 + 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5 + 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6 + 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6 + 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6 + 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7 + 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Appendix A. Change History [To Be Removed on Publication] . . . . 10 + A.1. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10 + A.2. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10 + A.3. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 10 + A.4. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11 + A.5. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11 + A.6. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11 + Appendix B. Proposed Status [To Be Removed on Publication] . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . . . 12 + + + + + + + + + + + + + + + + + + + + + + +Andrews Expires May 22, 2008 [Page 2] + +Internet-Draft Locally-served DNS Zones November 2007 + + +1. Introduction + + Experience has shown that there are a number of DNS [RFC 1034] [RFC + 1035] zones that all iterative resolvers and recursive nameservers + SHOULD, unless intentionally configured otherwise, automatically + serve. These zones include, but are not limited to, the IN-ADDR.ARPA + zones for the address space allocated by [RFC 1918] and the IP6.ARPA + zones for locally assigned unique local IPv6 addresses, [RFC 4193]. + + This recommendation is made because data has shown that significant + leakage of queries for these name spaces is occurring, despite + instructions to restrict them, and because it has therefore become + necessary to deploy sacrificial name servers to protect the immediate + parent name servers for these zones from excessive, unintentional, + query load [AS112] [I-D.draft-ietf-dnsop-as112-ops] + [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every + expectation that the query load will continue to increase unless + steps are taken as outlined here. + + Additionally, queries from clients behind badly configured firewalls + that allow outgoing queries for these name spaces but drop the + responses, put a significant load on the root servers (forward but no + reverse zones configured). They also cause operational load for the + root server operators as they have to reply to enquiries about why + the root servers are "attacking" these clients. Changing the default + configuration will address all these issues for the zones listed in + Section 4. + + [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled + locally. This document extends the recommendation to cover the IN- + ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and + IP6.ARPA zones for which queries should not appear on the public + Internet. + + It is hoped that by doing this the number of sacrificial servers + [AS112] will not have to be increased, and may in time be reduced. + + This recommendation should also help DNS responsiveness for sites + which are using [RFC 1918] addresses but do not follow the last + paragraph in Section 3 of [RFC 1918]. + +1.1. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + + + + +Andrews Expires May 22, 2008 [Page 3] + +Internet-Draft Locally-served DNS Zones November 2007 + + +2. Effects on sites using RFC 1918 addresses. + + For most sites using [RFC 1918] addresses, the changes here will have + little or no detrimental effect. If the site does not already have + the reverse tree populated the only effect will be that the name + error responses will be generated locally rather than remotely. + + For sites that do have the reverse tree populated, most will either + have a local copy of the zones or will be forwarding the queries to + servers which have local copies of the zone. Therefore this + recommendation will not be relevant. + + The most significant impact will be felt at sites that make use of + delegations for [RFC 1918] addresses and have populated these zones. + These sites will need to override the default configuration expressed + in this document to allow resolution to continue. Typically, such + sites will be fully disconnected from the Internet and have their own + root servers for their own non-Internet DNS tree. + + +3. Changes to Iterative Resolver Behaviour. + + Unless configured otherwise, an iterative resolver will now return + authoritatively (aa=1) name errors (RCODE=3) for queries within the + zones in Section 4, with the obvious exception of queries for the + zone name itself where SOA, NS and "no data" responses will be + returned as appropriate to the query type. One common way to do this + is to serve empty (SOA and NS only) zones. + + An implementation of this recommendation MUST provide a mechanism to + disable this new behaviour, and SHOULD allow this decision on a zone + by zone basis. + + If using empty zones one SHOULD NOT use the same NS and SOA records + as used on the public Internet servers as that will make it harder to + detect the origin of the responses and thus any leakage to the public + Internet servers. This document recommends that the NS record + defaults to the name of the zone and the SOA MNAME defaults to the + name of the only NS RR's target. The SOA RNAME should default to + "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a + mechanism to set these values. No address records need to be + provided for the name server. + + Below is an example of a generic empty zone in master file format. + It will produce a negative cache TTL of 3 hours. + + @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 @ 10800 + IN NS @ + + + +Andrews Expires May 22, 2008 [Page 4] + +Internet-Draft Locally-served DNS Zones November 2007 + + + The SOA RR is needed to support negative caching [RFC 2308] of name + error responses and to point clients to the primary master for DNS + dynamic updates. + + SOA values of particular importance are the MNAME, the SOA RR's TTL + and the negTTL value. Both TTL values SHOULD match. The rest of the + SOA timer values MAY be chosen arbitrarily since they are not + intended to control any zone transfer activity. + + The NS RR is needed as some UPDATE clients use NS queries to discover + the zone to be updated. Having no address records for the name + server is expected to abort UPDATE [RFC 2136] processing in the + client. + + +4. Lists Of Zones Covered + + The following subsections are intended to seed the IANA registry as + requested in the IANA Considerations Section. The zone name is the + entity to be registered. + +4.1. RFC 1918 Zones + + The following zones correspond to the IPv4 address space reserved in + [RFC 1918]. + + +----------------------+ + | Zone | + +----------------------+ + | 10.IN-ADDR.ARPA | + | 16.172.IN-ADDR.ARPA | + | 17.172.IN-ADDR.ARPA | + | 18.172.IN-ADDR.ARPA | + | 19.172.IN-ADDR.ARPA | + | 20.172.IN-ADDR.ARPA | + | 21.172.IN-ADDR.ARPA | + | 22.172.IN-ADDR.ARPA | + | 23.172.IN-ADDR.ARPA | + | 24.172.IN-ADDR.ARPA | + | 25.172.IN-ADDR.ARPA | + | 26.172.IN-ADDR.ARPA | + | 27.172.IN-ADDR.ARPA | + | 28.172.IN-ADDR.ARPA | + | 29.172.IN-ADDR.ARPA | + | 30.172.IN-ADDR.ARPA | + | 31.172.IN-ADDR.ARPA | + | 168.192.IN-ADDR.ARPA | + +----------------------+ + + + +Andrews Expires May 22, 2008 [Page 5] + +Internet-Draft Locally-served DNS Zones November 2007 + + +4.2. RFC 3330 Zones + + The following zones correspond to those address ranges from [RFC + 3330] that are not expected to appear as source or destination + addresses on the public Internet and to not have a unique name to + associate with. + + The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a + attempt to discourage any practice to provide a PTR RR for + 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse + mapping should exist, but the exact setup is out of the scope of this + document. Similar logic applies to the reverse mapping for ::1 + Section 4.3. The recommendations made here simply assume no other + coverage for these domains exists. + + +------------------------------+------------------------+ + | Zone | Description | + +------------------------------+------------------------+ + | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK | + | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK | + | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL | + | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET | + | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST | + +------------------------------+------------------------+ + +4.3. Local IPv6 Unicast Addresses + + The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for + the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291], + Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones: + + +-------------------------------------------+ + | Zone | + +-------------------------------------------+ + | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | + | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | + | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | + | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | + +-------------------------------------------+ + + Note: Line breaks and a escapes '\' have been inserted above for + readability and to adhere to line width constraints. They are not + parts of the zone names. + +4.4. IPv6 Locally Assigned Local Addresses + + Section 4.4 of [RFC 4193] already required special treatment of: + + + + +Andrews Expires May 22, 2008 [Page 6] + +Internet-Draft Locally-served DNS Zones November 2007 + + + +--------------+ + | Zone | + +--------------+ + | D.F.IP6.ARPA | + +--------------+ + +4.5. IPv6 Link Local Addresses + + IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered + by four distinct reverse DNS zones: + + +----------------+ + | Zone | + +----------------+ + | 8.E.F.IP6.ARPA | + | 9.E.F.IP6.ARPA | + | A.E.F.IP6.ARPA | + | B.E.F.IP6.ARPA | + +----------------+ + + +5. Zones that are Out-Of-Scope + + IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.57, and IPv6 + Centrally Assigned Local [RFC 4193] addresses are not covered here. + It is expected that IPv6 site-local addresses will be self correcting + as IPv6 implementations remove support for site-local addresses. + However, sacrificial servers for C.E.F.IP6.ARPA through + F.E.F.IP6.ARPA may still need to be deployed in the short term if the + traffic becomes excessive. + + For IPv6 Centrally Assigned Local addresses (L = 0) [RFC 4193], there + has been no decision made about whether the Regional Internet + Registries (RIRs) will provide delegations in this space or not. If + they don't, then C.F.IP6.ARPA will need to be added to the list in + Section 4.4. If they do, then registries will need to take steps to + ensure that name servers are provided for these addresses. + + This document also ignores IP6.INT. IP6.INT has been wound up with + only legacy resolvers now generating reverse queries under IP6.INT + [RFC 4159]. + + This document has also deliberately ignored names immediately under + the root domain. While there is a subset of queries to the root name + servers which could be addressed using the techniques described here + (e.g. .local, .workgroup and IPv4 addresses), there is also a vast + amount of traffic that requires a different strategy (e.g. lookups + for unqualified hostnames, IPv6 addresses). + + + +Andrews Expires May 22, 2008 [Page 7] + +Internet-Draft Locally-served DNS Zones November 2007 + + +6. IANA Considerations + + This document requests that IANA establish a registry of zones which + require this default behaviour. The initial contents of which are in + Section 4. Implementors are encouraged to check this registry and + adjust their implementations to reflect changes therein. + + This registry can be amended through "IETF Consensus" as per [RFC + 2434]. + + IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is + deployed in the reverse tree, delegations for these zones are made in + the manner described in Section 7. + + +7. Security Considerations + + During the initial deployment phase, particularly where [RFC 1918] + addresses are in use, there may be some clients that unexpectedly + receive a name error rather than a PTR record. This may cause some + service disruption until their recursive name server(s) have been re- + configured. + + As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA + namespaces, the zones listed above will need to be delegated as + insecure delegations, or be within insecure zones. This will allow + DNSSEC validation to succeed for queries in these spaces despite not + being answered from the delegated servers. + + It is recommended that sites actively using these namespaces secure + them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust + anchors. This will protect the clients from accidental import of + unsigned responses from the Internet. + + +8. Acknowledgements + + This work was supported by the US National Science Foundation + (research grant SCI-0427144) and DNS-OARC. + + +9. References + +9.1. Normative References + + [RFC 1034] + Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", + RFC 1034, STD 13, November 1987. + + + +Andrews Expires May 22, 2008 [Page 8] + +Internet-Draft Locally-served DNS Zones November 2007 + + + [RFC 1035] + Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND + SPECIFICATION", RFC 1035, STD 13, November 1987. + + [RFC 1918] + Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + RFC 1918, February 1996. + + [RFC 2119] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2136] + Vixie, P., Thomson, A., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC 2308] + Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2398, March 1998. + + [RFC 2434] + Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC 2606] + Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, June 1999. + + [RFC 3596] + Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IPv6", RFC 3596, October 2003. + + [RFC 4035] + Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC 4159] + Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, + August 2005. + + [RFC 4193] + Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + + + +Andrews Expires May 22, 2008 [Page 9] + +Internet-Draft Locally-served DNS Zones November 2007 + + + [RFC 4291] + Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + +9.2. Informative References + + [AS112] "AS112 Project", . + + [I-D.draft-ietf-dnsop-as112-ops] + Abley, J. and W. Maton, "AS112 Nameserver Operations", + draft-ietf-dnsop-as112-ops-00 (work in progress), + February 2007. + + [I-D.draft-ietf-dnsop-as112-under-attack-help-help] + Abley, J. and W. Maton, "I'm Being Attacked by + PRISONER.IANA.ORG!", + draft-ietf-dnsop-as112-under-attack-help-help-00 (work in + progress), February 2007. + + [RFC 3330] + "Special-Use IPv4 Addresses", RFC 3330, September 2002. + + +Appendix A. Change History [To Be Removed on Publication] + +A.1. draft-ietf-dnsop-default-local-zones-03.txt + + expanded section 4 descriptions + + Added references [RFC 2136], [RFC 3596], + [I-D.draft-ietf-dnsop-as112-ops] and + [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. + + Revised language. + +A.2. draft-ietf-dnsop-default-local-zones-02.txt + + RNAME now "nobody.invalid." + + Revised language. + +A.3. draft-ietf-dnsop-default-local-zones-01.txt + + Revised impact description. + + Updated to reflect change in IP6.INT status. + + + + + +Andrews Expires May 22, 2008 [Page 10] + +Internet-Draft Locally-served DNS Zones November 2007 + + +A.4. draft-ietf-dnsop-default-local-zones-00.txt + + Adopted by DNSOP. + + "Author's Note" re-titled "Zones that are Out-Of-Scope" + + Add note that these zone are expected to seed the IANA registry. + + Title changed. + +A.5. draft-andrews-full-service-resolvers-03.txt + + Added "Proposed Status". + +A.6. draft-andrews-full-service-resolvers-02.txt + + Added 0.IN-ADDR.ARPA. + + +Appendix B. Proposed Status [To Be Removed on Publication] + + This Internet-Draft is being submitted for eventual publication as an + RFC with a proposed status of Best Current Practice. + + +Author's Address + + Mark P. Andrews + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + US + + Email: Mark_Andrews@isc.org + + + + + + + + + + + + + + + + + +Andrews Expires May 22, 2008 [Page 11] + +Internet-Draft Locally-served DNS Zones November 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Andrews Expires May 22, 2008 [Page 12] + diff --git a/doc/private/branches b/doc/private/branches index bb66378725..66dacd3a09 100644 --- a/doc/private/branches +++ b/doc/private/branches @@ -26,6 +26,7 @@ jinmei-mmapzone-test open // mmap based zone file. very experimental, just for jinmei_libdnsng open jinmei_lrucache open libbind_clean open jinmei +make new marka_libdnsng open mlg-20000518 open explorer newresolver0 open @@ -95,6 +96,7 @@ skan_stats4 open explorer sp1213 open sp1324 new marka // 2007-06-29 05:40 +0000 sp1705 new +sp1705a new stats_lidl open v6source open v9_1 active // security fixes only