diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-00.txt deleted file mode 100644 index 0727f74505..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-00.txt +++ /dev/null @@ -1,505 +0,0 @@ - - -Network Working Group M. Kosters -Internet-Draft Network Solutions, Inc. -Expires: December 25, 2001 June 26, 2001 - - - DNSSEC Opt-in for Large Zones - draft-ietf-dnsext-dnssec-opt-in-00.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 December 25, 2001. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - In order for DNSSEC to be deployed operationally with large zones - and little operational impact, there needs to be included a - mechanism that allows for the separation of secure versus unsecure - views of zones. This needs to be done in a transparent fashion that - allows DNSSEC to be deployed in an incremental manner. This - document proposes a method using views to allow for incremental - growth of delegations that are registered as secure. This is - accomplished by extending the use of the NXT record to deal with - non-secure delegations as well as for non-existence. - - - - - - -Kosters Expires December 25, 2001 [Page 1] - -Internet-Draft DNSSEC Opt In June 2001 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 - References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kosters Expires December 25, 2001 [Page 2] - -Internet-Draft DNSSEC Opt In June 2001 - - -1. Introduction - - DNS is an unsecure system. The key features that give DNS its power - can also be its chief weaknesses. One feature is the facility to - delegate branches of information from one set of servers to another. - Currently, this is done in a non-cryptographically verified way that - allows spoofing attacks. For example, in July 1997, an alternative - domain registry called AlterNIC exploited this vulnerability to - redirect the www.netsol.com and www.internic.net websites to the - AtlerNIC website. If this delegated information had been - cryptographically verified, this attack would not have been able to - occur. - - In recent years, there has been much work within the IETF regarding - DNS security. There are a number of RFCs that integrate public key - technology within DNS to enable cryptographically-verified answers. - To this end, three new resource record types (RR's) have been - defined: - - o KEY - one of the public keys of the zone - o SIG - a signature of an accompanying RR set - o NXT - a record that indicates the range of labels to show - negative proof - - A zone's authoritative RR's are combined into groups for signing. A - set of RR's will be in the same group if and only if they have the - same name and the same RR type. Each group is then signed with each - of the zone's keys, and each of these signings produces one SIG - record. Each zone KEY RR can be verified hierarchically with a SIG - RR from the direct parent zone. For unsecure delegations, a NULL KEY - RR is inserted in the parent zone to verifiably attest the subdomain - is insecure. Finally, NXT RR's and their accompanying SIG RR's are - issued in the case of a negative reply. - - As a zone maintainer, transitioning to a secure zone has a high - overhead in the following areas: - - KEY RR - At a delegation point, the zone maintainer needs to place a NULL - KEY and accompanying SIG RR's when the child zone is not known to - be secure. - NXT RR - Each delegation needs to be lexigraphically ordered so that a NXT - RR can be generated and signed with SIG RR's. For large zone - operators, ordering the zone file is a very time-consuming - process. In the resolution process, NXT lookups require that the - server replace efficient hash structures with a lexigraphically - ordered search structure that degrades lookup performance. This - lookup performance is a critical element for a high-query rate - - -Kosters Expires December 25, 2001 [Page 3] - -Internet-Draft DNSSEC Opt In June 2001 - - - DNS server. - - Thus, the net effect is when one initially secures a zone as defined - in RFC2535[4], the amount of processing is massive because of the - following factors: - - 1. Zone ordering and maintenance for large zones is difficult and - expensive. - 2. Adding NULL KEY RR's, NXT RR's and their accompanying SIG RR's - for unsecure delegations will consume large amounts of memory - (six times the current memory requirements). - 3. Having a less efficient lookup algorithm to provide answers to - queries will degrade overall performance. - 4. There is very little initial payoff (anticipate only a small - fraction of delegations to be signed. This equates to less than - 1% over the first six months). - 5. Unsecured delegations are more expensive at the parent than - secure delegations (NULL KEY). - -2. Rationale - - As DNSSEC is initially deployed, it is anticipated that DNSSEC - adoption will be slow to materialize. It is also anticipated that - DNSSEC security resolution will be top-down. Thus for DNSSEC to be - widely adopted, the root zone and GTLD zones will need to be signed. - Based on the implications previously listed, a large zone maintainer - such as the administrator of COM, needs to create an infrastructure - that is an order of magnitude larger than its current state with - very little initial benefit. - - This document proposes an alternative opt-in approach that minimizes - the expense and complexity of DNSSEC adoption by large zones. This - is done by allowing for an alternate view with only secured - delegations. - -3. Protocol Additions - - The opt-in proposal allows for a zone operator to maintain two views - of its delegations - one being signed and the other not. The - non-DNSSEC view will have all delegations - both secured and - non-secured. The DNSSEC aware view will only have secured - delegations. It is assumed that neither view will have any innate - knowledge of the other's delegations. Thus, the cost of securing a - zone is proportional to the demand of its delegations with the added - benefit of no longer having to maintain NULL KEY RRs for unsecure - delegations. - - Since the opt-in model changes the semantics of the NXT RR, the - resolver needs to know if the zone itself follows a RFC2535[4] style - - -Kosters Expires December 25, 2001 [Page 4] - -Internet-Draft DNSSEC Opt In June 2001 - - - model or the opt-in model. An opt-in zone is identified by setting - bit 4 of the flags section within the KEY RR for that particular - zone. - - To determine which view each DNS query packet is to be queried - against, there is a simple algorithm to be followed: - - 1. The DNSSEC view MUST be queried when the DO bit is set within - the EDNS0 OPT meta RR as indicated in [6] Additionally, - 2. The DNSSEC view MUST be queried when the query type is SIG, KEY, - or NXT. - - If the query does not follow either case (1) or (2), the non-DNSSEC - view MUST be consulted by default. - - Since the DNSSEC view will have a subset of the actual delegations - of that zone, it will not be able to respond to an unsecured - delegation query. To that end, one of the two following events will - occur: - - 1) If the RR set exists within the unsecure view, the answer will - show up normally with in the Answer and Additional sections. - Additionally, the NXT RR from the secure view is folded into the - Authority section along with the related KEY RR's and its SIG in the - Additional section. The NXT RR is added to prove the answer does not - exist in the secure view. - - 2) If the RR set does not exist within the unsecure view, the RCODE - will be set to NXDOMAIN. Additionally, the NXT RR from the secure - view is sent in the Authority section along with the related KEY - RR's and its SIG in the Additional section. Again, the NXT RR is - added to prove the answer does not exist in the secure view. - - Example: - - Consider a zone with the secure names 3, 6, and 9, and unsecure - names 2, 4, 5, 7, and 8. - - Unsecured zone Contents: - - @ SOA - 2 NS - 3 NS - 4 NS - 5 NS - 6 NS - 7 NS - 8 NS - 9 NS - - -Kosters Expires December 25, 2001 [Page 5] - -Internet-Draft DNSSEC Opt In June 2001 - - - Secured zone Contents: - @ SOA, SIG SOA, NXT(3), SIG NXT - 3 NS, SIG NS, NXT(6), SIG NXT - 6 NS, SIG NS, NXT(9), SIG NXT - 9 NS, SIG NS, NXT(@), SIG NXT - - 1. A query for 5 RR type A with EDNS0 DO bit set would return with - the following response: - - - RCODE=NOERROR - Authority Section: - 5 NS - 3 NXT(6), SIG NXT - Additional Section: - KEY, SIG KEY - - - The secure server would see that 5 is lexographically between 3 - and 6 and therefore know that 5 is insecure. - - 2. A query for 55 RR type A with EDNS0 DO bit set would return with - the following response: - - - RCODE=NXDOMAIN - Authority Section: - SOA, SIG SOA, 3 NXT(6), SIG NXT - Additional Section: - KEY, SIG KEY - - - The secure server would see that 55 is lexographically between - 3 and 6 and therefore know that 55 is definitely does not exist - in the secure realm. - - 3. A query for 3 RR type KEY without EDNS DO bit set would return - with an response as defined in RFC2535[4]. - - 4. A Query for 3 RR type A, with EDNS0 DO bit set would return with - a response as defined in RFC2535[4]. - - 5. A Query for 6 RR type A, without EDNS0 DO bit set would return - with a response as defined in RFC1035[2]. - - - - - - - -Kosters Expires December 25, 2001 [Page 6] - -Internet-Draft DNSSEC Opt In June 2001 - - -4. Security Considerations - - This draft is different and separate from RFC2535[4] in that it - allows for secured delegation paths to exist but does not allow for - secure answers to unsecured delegations at the parent level. - Increased exposure will be marginal given that the children are - unsecure. - -5. IANA Considerations - - The IANA is requested to reserve the use of the fourth bit of the - KEY RR to indicate that the zone is an opt-in zone. - -6. Acknowledgements - - This document is based on a rough draft by Brian Wellington along - with input from Olafur Gudmundsson, David Blacka, and Mike - Schiraldi. - -References - - [1] Mockapetris, P.V., "Domain names - concepts and facilities", - RFC 1034, STD 13, Nov 1987. - - [2] Mockapetris, P.V., "Domain names - implementation and - specification", RFC 1035, STD 13, Nov 1987. - - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, BCP 14, March 1997. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [6] Conrad, D. R., "Indicating Resolver Support of DNSSEC (work in - progress)", August 2000. - - - - - - - - - - - - - -Kosters Expires December 25, 2001 [Page 7] - -Internet-Draft DNSSEC Opt In June 2001 - - -Author's Address - - Mark Kosters - Network Solutions, Inc. - 505 Huntmar Park Drive - Herndon, VA 22070 - US - - Phone: +1 703 948-3362 - EMail: markk@netsol.com - URI: http://www.netsol.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kosters Expires December 25, 2001 [Page 8] - -Internet-Draft DNSSEC Opt In June 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). 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. - - - - - - - - - - - - - - - - - - - -Kosters Expires December 25, 2001 [Page 9] - - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-01.txt new file mode 100644 index 0000000000..ecdf693516 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-01.txt @@ -0,0 +1,895 @@ + + +Network Working Group R. Arends +Internet-Draft Nominum, Inc. +Expires: May 2, 2002 M. Kosters + D. Blacka + Verisign, Inc. + November 1, 2001 + + + DNSSEC Opt-In + draft-ietf-dnsext-dnssec-opt-in-01 + +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 May 2, 2002. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + RFC 2535 defines a secure zone as completely signed. There are cases + where there is no need, it is not practical, or simply not possible + to maintain a completely signed zone. To allow administrators to + gradually adopt DNSSEC, a model, "Opt-In", is proposed that + generalizes the inclusion of unsigned records within a secure zone. + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 1] + +Internet-Draft DNSSEC Opt-In November 2001 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 2] + +Internet-Draft DNSSEC Opt-In November 2001 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system, RFC 1035 + [1], DNS security extensions, RFC 2535 [4], and DNSSEC terminology + RFC 3090 [5] is assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + + RRset: refers to a Resource Record Set, as defined by [3]. + + Delegation RRset: refers to a RRset of type NS that forms a zone cut. + That is, any NS RRsets except those residing at the zone apex. + + node: describes the set all RRsets for a single owner name. In other + words, all records in the zone with the same name (but possibly + differing types). + + secure node: refers to a node where all RRsets within the node are + signed, minus delegation RRsets. All signed nodes contain a + single NXT record. + + insecure node: refers to a node where none of the RRsets within the + node are signed. + + name: refers to the owner name of a node. + + The key words "MUST, "MUST NO", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 3] + +Internet-Draft DNSSEC Opt-In November 2001 + + +2. Overview + + In order to ease deployment of DNSSEC, it is desirable to have a + mechanism that generally allows for unsigned records to exist within + an otherwise secure zone. + + In the current definition of DNSSEC, RFC 2535 [4], there are already + two types of unsigned RRsets: delegation point NS RRsets and glue + RRsets. This document proposes a model, Opt-In, that generalizes the + capability to have unsigned records within a secure zone. This is + accomplished by extending the semantics of the NXT record using a + redundant bit in the type bit map. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 4] + +Internet-Draft DNSSEC Opt-In November 2001 + + +3. Protocol Additions + + In RFC 2535, a secured zone consists of a series of secured nodes, + where each node contains a signed NXT RR. The (non)existence of a + node is proven using the intervals defined by the NXT RR's owner + names and next values. The (non)existence of a RRset within a node + is proven using the type bit map in the NXT RR. + + Opt-In expands this definition by allowing insecure nodes to be + interleaved between secure nodes. Since this represents a change of + the interpretation of NXT records, resolvers must be able to + distinguish between RFC 2535 NXT records and Opt-In NXT records. + This is accomplished by tagging the NXT records that span (or + potentially span) insecure nodes. This tag is indicated by the + absence of the NXT bit in the type bit map. Since the NXT bit in the + type map merely indicates the existence of the record itself, this + bit is redundant and open for use as a tag. + + Using Opt-In, the existence or non-existence of insecure nodes is not + asserted by the tagged NXT records. This allows for the addition or + removal of insecure RRsets without recalculating and resigning the + NXT chain. However, Opt-In NXT records still assert the + (non)existence of secure nodes, and the existence of individual + RRsets within the secure nodes. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records + and RFC 2535 NXT records. At each secure node, the NXT record within + that node MUST either be RFC 2535 or Opt-In compliant. If it is not + Opt-In, there MUST NOT be any insecure nodes between it and the next + node. + + In summary, + + o An Opt-In NXT type is identified by a zero-valued (or not- + specified) NXT bit in the type bit map of the NXT record. + + o A RFC2535 NXT type is identified by a one-valued NXT bit in the + type bit map of the NXT record. + + and + + o In RFC 2535, NXT records indicate the existence or non-existence + of all nodes in the zone. + + o In Opt-In, tagged NXT records indicate the existence or non- + existence of all SECURE nodes in the zone. + + + + + +Arends, et al. Expires May 2, 2002 [Page 5] + +Internet-Draft DNSSEC Opt-In November 2001 + + +4. Benefits + + Using Opt-In allows administrators of large or rapidly changing zones + to minimize the overhead involved in maintaining the security of the + zone. One particular way that Opt-In accomplishes this is by + eliminating the need for "no-key" KEY records for insecure subzone + delegations. In RFC 2535, insecure delegations are required to have + an associated signed "no-key" KEY RR. Instead, under Opt-In, + insecure subzone delegation records are stored in insecure nodes. + For large, delegation-centric zones (like TLDs) this can lead to + substantial reductions in overhead. + + In addition, because the NXT chain for the zone does not have to be + changed when adding or removing insecure RRs, zones that may be + constantly adding and/or removing RRs can do so without incurring the + overhead associated with modifying and resigning the NXT chain. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 6] + +Internet-Draft DNSSEC Opt-In November 2001 + + +5. Examples + + Consider the zone EXAMPLE, shown below. This is a zone where all of + the NXT records are tagged as Opt-In. It consists of 5 nodes: 3 + secure nodes (EXAMPLE., FIRST-SECURE.EXAMPLE., and SECOND- + SECURE.EXAMPLE.) and 2 insecure nodes (NOT-SECURE.EXAMPLE., and + UNSIGNED.EXAMPLE.). + + Example A: Fully Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. SIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. SIG NS ... + EXAMPLE. KEY ... + EXAMPLE. SIG KEY ... + EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY + EXAMPLE. SIG NXT ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. SIG A ... + FIRST-SECURE.EXAMPLE. NXT SECOND-SECURE.EXAMPLE. A SIG + FIRST-SECURE.EXAMPLE. SIG NXT ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. KEY ... + SECOND-SECURE.EXAMPLE. SIG KEY ... + SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY + SECOND-SECURE.EXAMPLE. SIG NXT ... + + UNSIGNED.EXAMPLE. MX ... + + + In this example, a query for a signed RRset (e.g., "FIRST- + SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- + SECURE.EXAMPLE A") will result in a standard RFC 2535 response. A + query for a nonexistent RRset will result in a response that differs + from RFC 2535 only in the fact that the NXT record will be tagged as + Opt-In. + + A query for an insecure RR will return both the answer (in the Answer + or Authority section, as appropriate) and the corresponding Opt-In + NXT record to prove that it is not secure. + + + + + +Arends, et al. Expires May 2, 2002 [Page 7] + +Internet-Draft DNSSEC Opt-In November 2001 + + + Example A.1: Response to query for UNSECURE.EXAMPLE. MX + + + RCODE=NOERROR + + Answer Section: + UNSECURE.EXAMPLE. MX ... + + Authority Section: + SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY + SECOND-SECURE.EXAMPLE. SIG NXT ... + + Additional Section: + EXAMPLE. KEY ... + EXAMPLE. SIG KEY ... + + Similarly, a query for an RR that is delegated to an insecure subzone + will return both the referral and the corresponding Opt-In NXT record + to prove that it is not secure. + + Example A.2: Response to query for WWW.NOT-SECURE.EXAMPLE. A + + RCODE=NOERROR + + Authority Section: + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + FIRST-SECURE.EXAMPLE. NXT SECOND-SECURE.EXAMPLE. A SIG + FIRST-SECURE.EXAMPLE. SIG NXT ... + + Additional Section: + NS.NOT-SECURE.EXAMPLE. A ... + EXAMPLE. KEY ... + EXAMPLE. SIG KEY ... + + In Example A, the EXAMPLE. node MAY use either style of NXT record, + because there are no insecure nodes that occur between it and the + next node, FIRST-SECURE.EXAMPLE. In other words, Example A would + still be a valid zone if the NXT record for EXAMPLE. was changed to + the following RR: + + EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY NXT + + However, the other secure nodes (FIRST-SECURE.EXAMPLE. and SECOND- + SECURE.EXAMPLE.) MUST use Opt-In NXT records, because there are + insecure nodes in the range they define. (NOT-SECURE.EXAMPLE and + UNSECURE.EXAMPLE, respectively). + + + + + +Arends, et al. Expires May 2, 2002 [Page 8] + +Internet-Draft DNSSEC Opt-In November 2001 + + +6. Security Considerations + + Opt-In allows for unsigned names. All unsigned names are insecure, + and their validity can not be cryptographically proven. With Opt-In, + a malicious entity is able to insert, modify or delete unsigned names + in a secured zone. Thus, it is recommended to use RFC 2535 [4] where + possible and to use Opt-In where necessary. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 9] + +Internet-Draft DNSSEC Opt-In November 2001 + + +7. IANA Considerations + + None. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 10] + +Internet-Draft DNSSEC Opt-In November 2001 + + +8. Acknowledgments + + The contributions, suggestions and remarks of the following persons + (in alphabetic order) to this draft are acknowledged: + + Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf + Kolkman, Ted Lindgreen, Bill Manning, Dan Massey, Scott Rose, Mike + Schiraldi, Jakob Schlyter, Brian Wellington. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 11] + +Internet-Draft DNSSEC Opt-In November 2001 + + +References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [6] R. Conrad, D., "Indicating Resolver Support of DNSSEC", draft- + ietf-dnsext-dnssec-okbit-03 (work in progress), October 2001. + + +Authors' Addresses + + Roy Arends + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94063 + US + + Phone: +1 650 381 6000 + EMail: Roy.Arends@nominum.com + URI: http://www.nominum.com + + + Mark Kosters + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: markk@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 12] + +Internet-Draft DNSSEC Opt-In November 2001 + + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 13] + +Internet-Draft DNSSEC Opt-In November 2001 + + +Appendix A. Implementing Opt-In using "Views" + + In many cases, it may be convenient to implement an opt-in zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using opt-in tagged NXT records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the secure view must contain entire nodes. That is, if + any of the RRsets with a given name are signed in the combined opt-in + zone, all RRsets must be signed (and thus in the secure view). + + These two views may be combined at request time to provide a virtual, + single opt-in zone. The following algorithm is used when responding + to each query: + + V_A is the secure view as described above. + + V_B is the insecure view as described above. + + R_A is a response generated from V_A, following RFC 2535 [4]. + + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + + R_C is the response generated by combining R_A with R_B, as + described below. + + A query is DNSSEC-aware if it either has the DO bit [6] turned on, + or is for a DNSSEC-specific record type. + + + + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + + 2. Generate R_A. + + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + + 4. Generate R_B and combine it with R_A to form R_C: + + + +Arends, et al. Expires May 2, 2002 [Page 14] + +Internet-Draft DNSSEC Opt-In November 2001 + + + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + + 5. Return R_C. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 15] + +Internet-Draft DNSSEC Opt-In November 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires May 2, 2002 [Page 16]