diff --git a/doc/draft/draft-ietf-dnsext-dns-threats-01.txt b/doc/draft/draft-ietf-dnsext-dns-threats-02.txt similarity index 79% rename from doc/draft/draft-ietf-dnsext-dns-threats-01.txt rename to doc/draft/draft-ietf-dnsext-dns-threats-02.txt index c7cad2f2fd..694f85e510 100644 --- a/doc/draft/draft-ietf-dnsext-dns-threats-01.txt +++ b/doc/draft/draft-ietf-dnsext-dns-threats-02.txt @@ -5,10 +5,10 @@ Network Working Group D. Atkins -draft-ietf-dnsext-dns-threats-01.txt IHTFP Consulting +draft-ietf-dnsext-dns-threats-02.txt IHTFP Consulting R. Austein - InterNetShare, Incorporated - February 2002 + Bourgeois Dilettant + November 2002 Threat Analysis Of The Domain Name System @@ -55,9 +55,9 @@ Abstract -Atkins & Austein Expires 30 August 2002 [Page 1] +Atkins & Austein Expires 10 May 2003 [Page 1] -draft-ietf-dnsext-dns-threats-01.txt February 2002 +draft-ietf-dnsext-dns-threats-02.txt November 2002 1. Introduction @@ -111,9 +111,9 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 -Atkins & Austein Expires 30 August 2002 [Page 2] +Atkins & Austein Expires 10 May 2003 [Page 2] -draft-ietf-dnsext-dns-threats-01.txt February 2002 +draft-ietf-dnsext-dns-threats-02.txt November 2002 This note assumes that the reader is familiar with both the DNS and @@ -167,9 +167,9 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 -Atkins & Austein Expires 30 August 2002 [Page 3] +Atkins & Austein Expires 10 May 2003 [Page 3] -draft-ietf-dnsext-dns-threats-01.txt February 2002 +draft-ietf-dnsext-dns-threats-02.txt November 2002 be prohibitively high. Even more important, however, is that the @@ -223,9 +223,9 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 -Atkins & Austein Expires 30 August 2002 [Page 4] +Atkins & Austein Expires 10 May 2003 [Page 4] -draft-ietf-dnsext-dns-threats-01.txt February 2002 +draft-ietf-dnsext-dns-threats-02.txt November 2002 most likely to be successful when the victim is in a known state, @@ -279,9 +279,9 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 -Atkins & Austein Expires 30 August 2002 [Page 5] +Atkins & Austein Expires 10 May 2003 [Page 5] -draft-ietf-dnsext-dns-threats-01.txt February 2002 +draft-ietf-dnsext-dns-threats-02.txt November 2002 - Attacker's response includes one or more RRs with DNS names in @@ -335,9 +335,9 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 -Atkins & Austein Expires 30 August 2002 [Page 6] +Atkins & Austein Expires 10 May 2003 [Page 6] -draft-ietf-dnsext-dns-threats-01.txt February 2002 +draft-ietf-dnsext-dns-threats-02.txt November 2002 furnished by the user's ISP and advertised to the client via DHCP or @@ -391,9 +391,9 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 -Atkins & Austein Expires 30 August 2002 [Page 7] +Atkins & Austein Expires 10 May 2003 [Page 7] -draft-ietf-dnsext-dns-threats-01.txt February 2002 +draft-ietf-dnsext-dns-threats-02.txt November 2002 amplifiers, since DNS response packets tend to be significantly @@ -418,6 +418,46 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 if we cannot conceive of a plausible scenario involving this attack today. This implies that some mitigation of this risk is required. + Note that it's necessary to prove the non-existance of applicable + wildcard RRs as part of the authenticated denial mechanism, and that, + in a zone that is more than one label deep, such a proof may require + proving the non-existance of multiple discrete sets of wildcard RRs. + +2.7. Wildcards + + Much discussion has taken place over whether and how to provide data + integrity and data origin authentication for "wildcard" DNS names. + Conceptually, RRs with wildcard names are patterns for synthesizing + RRs on the fly according to the matching rules described in section + 4.3.2 of RFC 1034. While the rules that control the behavior of + wildcard names have a few quirks that can make them a trap for the + unwary zone administrator, it's clear that a number of sites make + heavy use of wildcard RRs, particularly wildcard MX RRs. + + In order to provide the desired services for wildcard RRs, we need to + prove two things: + + - We need to prove the existance of the wildcard RR itself (that is, + we need to prove that the synthesis rule exists), and + + - We need to prove the non-existance of any RRs which, if they + existed, would make the wildcard RR irrelevant according to the + synthesis rules the way in which wildcards are used (that is, we + need to prove that the synthesis rule is applicable). + + + +Atkins & Austein Expires 10 May 2003 [Page 8] + +draft-ietf-dnsext-dns-threats-02.txt November 2002 + + + Note that this makes the wildcard proof mechanism dependent upon the + authenticated denial mechanism described in the previous section. + + DNSSEC does include mechanisms by which it is possible to furnish + wildcard proofs along the lines described above. + 3. Weaknesses of DNSSEC DNSSEC has some problems of its own: @@ -444,14 +484,6 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 topic for another document....) - Like DNS itself, DNSSEC's trust model is almost totally - - - -Atkins & Austein Expires 30 August 2002 [Page 8] - -draft-ietf-dnsext-dns-threats-01.txt February 2002 - - hierarchical. While DNSSEC does allow resolvers to have special additional knowledge of public keys beyond those for the root, in the general case the root key is the one that matters. Thus any @@ -468,6 +500,14 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 - DNSSEC creates a requirement of loose time synchronization between the resolver and the host creating the DNSSEC signatures. Prior to DNSSEC, all time-related actions in DNS could be performed by a + + + +Atkins & Austein Expires 10 May 2003 [Page 9] + +draft-ietf-dnsext-dns-threats-02.txt November 2002 + + machine that only knew about "elapsed" or "relative" time. Because the validity period of a DNSSEC signature is based on "absolute" time, a resolver must have the same concept of absolute time in @@ -479,6 +519,20 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 generating signatures whose validity period does not match what the signer intended. + - The mechanism for wildcard proofs in DNSSEC is fairly painful. At + various times there have been questions as to whether the proof + mechanism is completely airtight and whether it would be worthwhile + to optimize the wildcard proof mechanism for the common case in + which wildcards do not exist, but the main problem is just the + inherent complexity of the wildcard mechanism itself. This + complexity probably makes the code for generating and checking + wildcard proofs somewhat fragile, but since the alternative of + giving up wildcards entirely is not practical due to widespread + use, we are going to have to live with wildcards, and the question + just becomes one of whether or not the proposed optimizations would + make DNSSEC's wildcard proof mechanisms more or less fragile. + + 4. Other issues [Odds and ends that don't yet fit anywhere else, to be revised...] @@ -501,14 +555,15 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 limited or closed environment such as a DHCP server updating a local DNS name server. - - -Atkins & Austein Expires 30 August 2002 [Page 9] - -draft-ietf-dnsext-dns-threats-01.txt February 2002 - - Major issues arise when trying to use dynamic update on a secure + + + +Atkins & Austein Expires 10 May 2003 [Page 10] + +draft-ietf-dnsext-dns-threats-02.txt November 2002 + + zone. TSIG can similarly be used in a limited fashion to authenticate the client to the server, but TSIG only protects DNS transactions, not the actual data, and the TSIG is not inserted into @@ -537,12 +592,45 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 to multiple entities, each of whom may require different kinds of access. For example, Alice may need to be able to add new nodes to the zone or change existing nodes, but not remove them; Bob may need - to be able to remove zones but not add them; Charlie may need to be + to be able to remove zones but not add them; Carol may need to be able to add, remove, or modify nodes, but only A records. NOTE: Scaling properties of the key management problem here is a particular concern that needs more study. +4.3. Securing DNS Zone Replication + + As discussed in previous sections, DNSSEC per se attempts to provide + data integrity and data origin authentication services on top of the + normal DNS query protocol. Using the terminology discussed in [SEC- + CONS], DNSSEC provides "object security" for the normal DNS query + protocol. For purposes of replicating entire DNS zones, however, + DNSSEC does not provide object security, because zones include + unsigned NS RRs and glue at delegation points. Use of TSIG to + protect zone transfer (AXFR or IXFR) operations provides "channel + security", but still does not provide object security for complete + zones, so the trust relationships involved in zone transfer are still + very much a hop-by-hop matter of name server operators trusting other + name server operators, rather than an end-to-end matter of name + + + +Atkins & Austein Expires 10 May 2003 [Page 11] + +draft-ietf-dnsext-dns-threats-02.txt November 2002 + + + server operators trusting zone administrators. + + Zone object security was not an explicit design goal of DNSSEC, so + failure to provide this service should not be a surprise. + Nevertheless, there are some zone replication scenarios for which + this would be a very useful additional service, so this seems like a + useful area for future work. In theory it should not be difficult to + zone object security as a backwards compatible enhancement to the + existing DNSSEC model, but the DNSEXT WG has not yet discussed either + the desirability of or the requirements for such an enhancement. + 5. Conclusion Based on the above analysis, the DNSSEC extensions do appear to solve @@ -550,19 +638,9 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 Security Considerations - This entire document is about security considerations of the DNS. We - believe that deploying DNSSEC will help to address some, but not all, - of the known threats to with DNS. - - - - - - -Atkins & Austein Expires 30 August 2002 [Page 10] - -draft-ietf-dnsext-dns-threats-01.txt February 2002 - + This entire document is about security considerations of the DNS. + The authors believe that deploying DNSSEC will help to address some, + but not all, of the known threats to with DNS. IANA Considerations @@ -570,12 +648,18 @@ IANA Considerations Acknowledgments - This note is based both previous published works by others and on on - a number of discussions both public and private over a period of many + This note is based both previous published works by others and on a + number of discussions both public and private over a period of many years, but particular thanks go to Steve Bellovin, Dan Bernstein, - Randy Bush, Olafur Gudmundsson, Allison Mankin, Paul Vixie, and our - libel lawyers at the firm of Dewey, Chetham, & Howe, none of whom are - responsible for what the authors did with their ideas. + Randy Bush, Olafur Gudmundsson, Allison Mankin, Paul Vixie, and any + other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups + whose names and contributions the authors have forgotten, none of + whom are responsible for what the authors did with their ideas. + + The authors would also like to thank Paul Mockapetris and Xunhua + Wang, both of whom sent useful information to the authors, about + which the authors have, as yet, done absolutely nothing. We were + listening, really, we just ran out of time before the draft deadline. References @@ -583,6 +667,15 @@ References Break-Ins", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. + + + + +Atkins & Austein Expires 10 May 2003 [Page 12] + +draft-ietf-dnsext-dns-threats-02.txt November 2002 + + [Galvin93] Design team meeting summary message posted to dns- security@tis.com mailing list by Jim Galvin on 19 November 1993. @@ -611,15 +704,6 @@ References [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. - - - - -Atkins & Austein Expires 30 August 2002 [Page 11] - -draft-ietf-dnsext-dns-threats-01.txt February 2002 - - [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. @@ -639,6 +723,20 @@ draft-ietf-dnsext-dns-threats-01.txt February 2002 [DNSSEC-ZONE-STATUS] Lewis, E., "DNS Security Extension Clarification on Zone Status" RFC 3090, March 2001. + + + + +Atkins & Austein Expires 10 May 2003 [Page 13] + +draft-ietf-dnsext-dns-threats-02.txt November 2002 + + + [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture + Board, "Guidelines for Writing RFC Text on Security + Considerations", work in progress (draft-iab-sec-cons-01.txt), + October 2002. + Author's addresses: Derek Atkins @@ -646,14 +744,12 @@ Author's addresses: 6 Farragut Ave Somerville, MA 02144 USA + Email: derek@ihtfp.com Rob Austein - InterNetShare, Incorporated - 325M Sharon Park Drive, Suite 308 - Menlo Park, CA 94025 - USA - sra@hactrn.net + + Email: sra@hactrn.net @@ -671,4 +767,20 @@ Author's addresses: -Atkins & Austein Expires 30 August 2002 [Page 12] + + + + + + + + + + + + + + + + +Atkins & Austein Expires 10 May 2003 [Page 14] diff --git a/doc/draft/draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt b/doc/draft/draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt new file mode 100644 index 0000000000..e35489156f --- /dev/null +++ b/doc/draft/draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt @@ -0,0 +1,728 @@ + + +DNSEXT (Independent submission) O. Kolkman +Internet-Draft RIPE NCC +Expires: March 2, 2003 J. Ihren + Autonomica + R. Arends + A.R.E.N.D.S. + September 2002 + + + DNSSEC Wildcard Optimization + draft-olaf-dnsext-dnssec-wildcard-optimization-01.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 2, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + Secure denial of the existence of wildcards may lead to a large + number of NXT RRs and associated SIG RRs in DNS responses, even in + the common case when wildcards are not present in the zone. This + optimization uses one bit from the NXT type array to signal that + there is no closer wildcard in the zone for a given query name. This + reduces the packet size and the need for executing slow, and + complicated, code paths in common queries. In cases where there are + no wildcard RRs in the zone (i.e. the root zone) only one NXT RR and + + + +Kolkman, et al. Expires March 2, 2003 [Page 1] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + + corresponding SIG is needed for denial of existence of the wildcard. + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 RFC2535 Wildcard Processing . . . . . . . . . . . . . . . . 3 + 1.2 Signalling the Existence of a Wildcard . . . . . . . . . . . 3 + 2. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . 4 + 2.1 Server Side . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1.1 Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1.2 Server Responses . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1.3 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2 Resolver Side . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 + 5. Internationalization Considerations . . . . . . . . . . . . 6 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Document Changes . . . . . . . . . . . . . . . . . . . . . . 6 + 7.1 draft 00->01 . . . . . . . . . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 + A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + A.1 Zone without wildcards . . . . . . . . . . . . . . . . . . . 8 + A.1.1 Optimized proof . . . . . . . . . . . . . . . . . . . . . . 8 + A.1.2 RFC2535 proof . . . . . . . . . . . . . . . . . . . . . . . 8 + A.2 Zone with wildcards . . . . . . . . . . . . . . . . . . . . 9 + A.2.1 Optimized proof . . . . . . . . . . . . . . . . . . . . . . 10 + A.2.2 NXDOMAIN with additional proof for no wildcard . . . . . . . 10 + A.2.3 Another Optimized Proof . . . . . . . . . . . . . . . . . . 11 + A.2.4 Denial of Existence of Closer Match . . . . . . . . . . . . 11 + A.2.5 The NXT 'next name' Proving Existence of a Wildcard . . . . 12 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + + +Kolkman, et al. Expires March 2, 2003 [Page 2] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + +1. Introduction + + Wildcards make authenticated denial of existence complex. Many zones + do not contain wildcards but still incur a penalty. If the NXT RR + contains an indication that a wildcard match can not exist then less + DNSSEC related RRs and less computation are needed to authoritatively + deny the existence of a name in the zone. + +1.1 RFC2535 Wildcard Processing + + RFC2535 [1] specifies that the non-existence of a match against a + wildcard is proven by a set of relevant NXT records. In practice + this will result to at least 2 NXT RRs and corresponding SIGs being + returned. There are cases where the denial of the existence of + wildcards will need many more than 2 NXT RRs. Even in zones that do + not use wildcards this will lead to complex answers for which the + resolvers will need to follow NXT chains and which are hard to + troubleshoot by operators. + +1.2 Signalling the Existence of a Wildcard + + The NXT RR, used to the prove the non-existence of data, uses a type + bit-map to track which types are available for a given name. We + propose to use one bit (see section Section 3) in the type bitmap to + signal if a wildcard is available in a zone. We refer to this bit as + the "NOWILD-bit". + + If the NOWILD-bit is set to 1 then the NXT RR signals that there is + no wildcard match possible against the query name, only if the bit is + set to 0 further processing needs to be done. For zones without + wildcards the NOWILD-bit MAY always be set to 1. + + The following optimizations are realized: + + o Servers and resolvers will only have to execute a slow and + somewhat complicated code paths if wildcard are present in the + zone. + + o Packet size of answers reduce in most common cases; for the root + zone the authority section only contains one NXT RR with + associated SIGs instead of two NXT RRs with associated SIGs. + + o In case of absence of wildcards-matches answers will be easier to + interpret by human operators troubleshooting responses; + + + + + + + +Kolkman, et al. Expires March 2, 2003 [Page 3] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + +2. DNSSEC Protocol Changes + + This is an update to the RFC2535 protocol. Resolvers MUST implement + these changes. Servers MAY implement these changes. + +2.1 Server Side + +2.1.1 Zone Signing + + Servers that implement the optimization MAY perform the following + actions at zone signing time. + + At zone signing time, when the NXT RRs are generated, the NOWILD-bit + MUST be set to 0 if for an ownername 'label(j).label(j-1).label(j-2) + ... label(0).' there is no wildcard name '*.label(i).label(i-1) ... + label(0).' in the zone for all i < j. In other words the label is + set to 0 if there exists a wildcard that would match QNAME=ownername + while ignoring the possible existence of a domain name between the + ownername and the wildcard domain. For all other ownernames the bit + MUST be set to 1. + + If, because of implementation or policy issues, the algorithm in the + previous paragraph is not applied then the bit MUST be set to 0 for + all NXT RRs in the zone. Servers that do do not implement the + optimization have already set their NOWILD bit to 0 by virtue of the + requirements of RFC2535 section 5.2. + + When the algorithm is applied a NXT RR that proves the non-existence + of a full match of the QNAME will also prove, when it's NOWILD-bit is + set to 1, that there is no match of the QNAME to any wildcard that + may exist in the zone + +2.1.2 Server Responses + + When queried for a name for which there is no match, i.e. no full + and no wildcard match, in the zone: + + o Servers MUST return the NXT RR that proves the non-existence of + the query name in the NXDOMAIN response. If there is no match for + a wildcard and the NOWILD-bit is set to 1 at signing time and the + one NXT RR is sufficient. If the NOWILD-bit for the NXT RR that + proves non-existence of the query name is set to 0 then NXT RRs + that prove the non-existence of possible wildcard matches MUST be + returned as well. + + When queried for a name for which there is a match in the zone: + + o If the match is an exact match than no NXT RRs are returned in the + + + +Kolkman, et al. Expires March 2, 2003 [Page 4] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + + additional section. + + o Servers for zones that contain one or more wildcards MUST return + the NXT RRs that prove the non-existence of the exact match. They + must also provide proof that there is no closer match for the + QNAME than the match returned in the answer section. + + The proof algorithm for non-existence of wildcards, an exact match or + closer matches conforms to RFC2535. + +2.1.3 Dynamic DNS + + When dynamically adding or removing a name that does not contains + wildcards, the 'next name' for the name immediately above the + inserted, or deleted name needs to be updated. The NOWILD bit of the + inserted name is to be set according to the procedure as described in + Section 2.1.1. Except for setting the NOWILD bit this is similar to + the RFC2535 procedure. + + If a name containing a wildcard is deleted from a zone one has to + verify if, for all names in the zone with the bit set to 0, the + NOWILD bit can be toggled. If a name containing a wildcard is added + one has to verify if, for all the names in the zone, the bit needs to + be set to 0. + + The NOWILD bit is not to be modified during an update of a name that + already exists in the zone. + + Dynamic updates of names that contain wildcards may lead to + performance penalties for large dynamic zones and one MAY therefore + choose not to perform the NOWILD optimization for dynamic zones. + +2.2 Resolver Side + + When receiving an answer to a query a resolver MUST assess if the + answer is a result of a wildcard match. If the result is an exact + match then there will be no NXT RRs in the authority section. + + If the answer is a wildcard match then the resolver will need to + verify that the exact name does not exist. The NXT RRs in the + additional section, which per definition have their NOWILD-bit set to + 0, will need to prove that there is no closer match. ( conforming to + RFC2535). + + If the response is NXDOMAIN (i.e. no match at all) then the resolver + MUST verify if the NXT RR proves the non-existence of the exact match + in the zone. No further NXT RRs are needed if the NXT RR has it's + NOWILD-bit set to 1. A DNS packet containing an NXDOMAIN response + + + +Kolkman, et al. Expires March 2, 2003 [Page 5] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + + accompanied by a NXT RR that has it's NOWILD-bit set to 0 will need + to contain proof that there are no wildcard matches against the QNAME + (conforming to RFC2535 ). + + The NXT data and the NOWILD-bit together supply the proof on the non- + existence of a wildcard. There is one situation where the NOWILD-bit + is set to 1 but the NXT's 'next name' proves that there is a + wildcard. This is when the 'next name' itself contains a wildcard. + Resolvers that verify NXDOMAIN replies MUST verify the NXT 'next + name' first before the NOWILD-bit. Also see example Appendix A.2.5. + + The fact that resolvers that obtain an answer with a NXT RR's NOWILD + set to 1 do not receive additional proof for the non-existence of + wildcards is incompatible with RFC2535. + +3. IANA Considerations + + Although there is no RR record associated the NOWILD-bit. The value + of the bit must be registered as a DNS RR-type. To not cause the NXT + type bitmap to grow beyond 4 octets unnecessary we propose to reuse + type code 31 (the EID type code is undocumented). + +4. Security Considerations + + The draft provides an optimization for wildcard handling. Resolvers + MUST verify for the denial of existence of matches or the denial of + existence of closer matches when an answer is returned and the + NOWILD-bit is set to 0. + +5. Internationalization Considerations + + There are no internationalization considerations. + +6. Acknowledgements + + Olafur Gudmundsson, Daniel Karrenberg and Ed Lewis for providing + critique and input on earlier versions of this document. + +7. Document Changes + +7.1 draft 00->01 + + Reordered and reworded the 'protocol changes' section. We tried + to make the fact that resolvers must and servers may implement + this optimization more explicit. + + Change from using the SIG bit to another bit in the NXT type- + bitmap, changed the name of the bit and added IANA considerations. + + + +Kolkman, et al. Expires March 2, 2003 [Page 6] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + + Note that the meaning of the bit being set and unset are changed + because of the default setting. Because of the fact that we want + to maintain backward compatibility with servers that do not + implement this bit and the bit in the typemap is currently set to + 0 the default behaviour should be follow old-style NXT proof. + + Corrected mistakes in the examples. + + Various style and spelling corrections. + +Normative References + + [1] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + 1016 AB Amsterdam + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + SE + + EMail: johani@autonomica.se + + + Roy Arends + A.R.E.N.D.S. + Bankastraat 41-e + 1094 EB Amsterdam + NL + + Phone: +31206931681 + EMail: Roy@logmess.com + + + + + +Kolkman, et al. Expires March 2, 2003 [Page 7] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + +Appendix A. Examples + +A.1 Zone without wildcards + + In the following example zone file there are no wildcards. All + NOWILD bits are set to 1. The actual SIG RRs and the KEY RRs are + left out from the zone data and type bitmaps for clarity only. + + $ORIGIN example. + @ IN SOA + @ NXT a SOA NXT NOWILD ; NOWILD-bit set to 1 + a A 10.0.0.1 + a NXT a.b A NXT NOWILD ; NOWILD-bit set to 1 + a.b A 10.0.0.2 + a.b NXT a.c A NXT NOWILD ; NOWILD-bit set to 1 + a.c A 10.0.0.4 + a.c NXT a.b.c A NXT NOWILD ; NOWILD-bit set to 1 + a.b.c A 10.0.0.5 + a.b.c NXT f A NXT NOWILD ; NOWILD-bit set to 1 + f A 10.0.0.6 + f NXT @ A NXT NOWILD ; NOWILD-bit set to 1 + + +A.1.1 Optimized proof + + A query for any existing name will return a signed answer without NXT + RRs in the authority section. A query for any non existing name will + only return 1 NXT RR proving the non-existence of the QNAME in the + zone and, by virtue of the NOWILD-bit being 1, this is sufficient + proof there is no wildcard. + + QNAME= d.b.c.example. QTYPE=A + + RCODE=NXDOMAIN + ;; Authority + example. SOA + SIG SOA + a.b.c.example. NXT f.example. A NXT NOWILD + SIG NXT + ;; Additional + (... skipped ... ) + + +A.1.2 RFC2535 proof + + For comparison we supply the same answer without the optimization + applied i.e. NOWILD set to 0 for all NXT RRs in the zone. The + answer needs to contain prove that *.b.c.example, *.c.example and + + + +Kolkman, et al. Expires March 2, 2003 [Page 8] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + + *.example do not exist, unless a name that exists in the zone + terminates the possible match of those wildcards against the QNAME. + + QNAME= d.b.c.example. QTYPE=A + + RCODE=NXDOMAIN + ;; Authority + example. SOA + SIG SOA + a.b.c.example. NXT f.example. A NXT + SIG NXT + ; proofs non-existence of exact match. + + a.c.example. NXT a.b.c.example. A NXT + SIG NXT + ; proofs non-existence of *.b.c.example. + + + ;; Additional + (... skipped ... ) + + Note that the existence of 'a.b.c.example NXT' RR terminates a + wildcard match of QNAME against *.c.example. and *.example. So the + answer packet does not need to contain further proof for the non- + existence of those wildcards. However, a resolver will have to + execute logic to verify that the existence of 'a.b.c.example.' + terminates the possible match of the QNAME against the possible + wildcards and that the answer is therefore complete. + +A.2 Zone with wildcards + + In the following example zone file there is a wildcard. Some NOWILD + bits are set to 1, others for which there is no wildcard in the zone + if the leftmost labels are chopped off, have there NOWILD-bit set to + 0. The actual SIG RRs and the KEY RRs at the apex are left out for + clarity. The queries for which a wildcard match is returned will + have the NOWILD-bit set to 0, there proof for the non-existing closer + match is to be supplied and checked by the resolver. + + + + + + + + + + + + + +Kolkman, et al. Expires March 2, 2003 [Page 9] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + + $ORIGIN example. + @ IN SOA + @ NXT a SOA NXT NOWILD ; NOWILD-bit set to 1 + a A 10.0.0.1 + a NXT a.b A NXT NOWILD ; NOWILD-bit set to 1 + a.b A 10.0.0.2 + a.b NXT *.c A NXT NOWILD ; NOWILD-bit set to 1 + *.c A 10.0.0.3 + *.c NXT a.c A NXT SIG ; NOWILD-bit set to 0 + a.c A 10.0.0.4 + a.c NXT a.b.c A NXT SIG ; NOWILD-bit set to 0 + a.b.c A 10.0.0.5 + a.b.c NXT f A NXT SIG ; NOWILD-bit set to 0 + f A 10.0.0.6 + f NXT @ A NXT NOWILD ; NOWILD-bit set to 1 + + +A.2.1 Optimized proof + + QNAME= c.a.a.example. QTYPE=A + + RCODE=NXDOMAIN + ;; Authority + example. SOA + SIG SOA + a.example. NXT a.b.example. A NXT SIG NOWILD + ; NOWILD-bit set to 1 proves no full + ; match and no wildcards that match + ; QNAME + SIG NXT + + + ;; Additional + (... skipped ... ) + + +A.2.2 NXDOMAIN with additional proof for no wildcard + + The following example contains a NXDOMAIN answer and the proof that + there is no wildcard match. + + + + + + + + + + + +Kolkman, et al. Expires March 2, 2003 [Page 10] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + + QNAME= e.example. QTYPE=A + + RCODE=NXDOMAIN + ;; Authority + example.example SOA + SIG SOA + a.b.c.example. NXT f.example. A NXT SIG ; NOWILD-bit set to 0, + ; proves no full match + SIG NXT + example. NXT a.example A NXT SIG NOWILD ; NOWILD-bit set to 1, + ; proves no *.example. + + + ;; Additional + (... skipped ... ) + + +A.2.3 Another Optimized Proof + + The following example contains a NXDOMAIN answer and the proof that + there is no wildcard match. In this particular case the proof is + optimized because of the NOWILD-bit on the f NXT RR being set to + zero. + + QNAME= g.example. QTYPE=A + + RCODE=NXDOMAIN + ;; Authority + example.example SOA + SIG SOA + f.example. NXT example. A NXT NOWILD ; NOWILD-bit set to 1 + ; proves no full match + + ;; Additional + (... skipped ... ) + + +A.2.4 Denial of Existence of Closer Match + + The following example contains an answer with wildcard expansion and + the proof that there is no closer match. This is similar to a + RFC2535 proof of non-existence. + + + + + + + + + +Kolkman, et al. Expires March 2, 2003 [Page 11] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + + QNAME= d.b.c.example. QTYPE=A + + RCODE=ANSWER + ;; Answer + d.b.c.example. A 10.0.0.3 ; expansion of *.c + SIG A (labelcount=2) ; labelcount proofs wildcard + ; example + ;; Authority + example.example. SOA + SIG SOA + a.b.c.example. NXT f.example. A NXT SIG ; NOWILD-bit set to 0, + ; proves no exact match, + SIG NXT + a.c.example. NXT a.b.c.example. A NXT SIG ; NOWILD-bit set to 0 + ; proves non-existence of + ; *.b.c.example. + ; No further proofs needed + + ;; Additional + (... skipped ... ) + + +A.2.5 The NXT 'next name' Proving Existence of a Wildcard + + In the zone above the a.b NXT RR has it's NOWILD-bit set to 1. If + one would query for '#.c' which canonically orders between a.b and + *.c one would get back "a.b NXT *.c". A attacker can use the this + NXT RR in a malformed NXDOMAIN response. + + QNAME= #.c.example. QTYPE=A + + RCODE=NXDOMAIN ; Black hat answer !!!! + ;; Authority + example.example SOA + SIG SOA + a.b.example. NXT *.c.example. A NXT NOWILD ; NOWILD-bit set to 1 + ; but *.c exists + + + + + + + + + + + + + + +Kolkman, et al. Expires March 2, 2003 [Page 12] + +Internet-Draft DNSSEC Wildcard Optimization September 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires March 2, 2003 [Page 13] +