+++ /dev/null
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-Internet-Draft DNSSEC Opt-In November 2001
-
-
-7. IANA Considerations
-
- None.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires May 2, 2002 [Page 10]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
--- /dev/null
+Network Working Group R. Arends
+Internet-Draft Nominum, Inc.
+Expires: December 26, 2002 M. Kosters
+ D. Blacka
+ Verisign, Inc.
+ June 27, 2002
+
+
+ DNSSEC Opt-In
+ draft-ietf-dnsext-dnssec-opt-in-02
+
+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 26, 2002.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ In RFC 2535, delegations to unsigned subzones are cryptographically
+ secured. Maintaining this cryptography is not practical or
+ necessary. This document describes an "Opt-In" model that allows
+ administrators to omit this cryptography and manage the cost of
+ adopting DNSSEC.
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 1]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+Table of Contents
+
+ 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
+ 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+ A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 16
+ B. Changes from Prior Versions . . . . . . . . . . . . . . . . . 18
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 2]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+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].
+
+ covering NXT record/RRset: is the NXT record used to prove
+ (non)existance of a particular name or RRset. This means that for
+ a RRset or name 'N', the covering NXT record has the name 'N', or
+ has an owner name less than 'N' and "next" name greater than 'N'.
+
+ delegation: refers to a NS RRset with a name different from the
+ current zone apex (non-zone-apex), signifying a delegation to a
+ subzone.
+
+ secure delegation: refers to the NS, DS, NXT and SIG RRsets for a
+ non-zone-apex owner name, signifying a delegation to a DNSSEC
+ signed subzone.
+
+ 2535/DS insecure delegation: refers to the NS, NXT, and SIG RRsets
+ for a non-zone-apex owner name, signifying a delegation to an
+ unsigned subzone. This differs from the secured delegation by the
+ absence of a DS RRset, marked by the zero value for the DS type
+ code in the NXT type map.
+
+ Opt-In insecure delegation: refers to the NS RRset for a non-zone-
+ apex owner name where the covering NXT record uses the Opt-In
+ methodology described in this document.
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 3]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+2. Overview
+
+ The cost to cryptographically secure delegations to unsigned zones is
+ high for large delegation-centric zones and zones where insecure
+ delegations will be updated rapidly. For these zones, the costs of
+ maintaining the NXT record chain may not be relative to the gain of
+ cryptographically securing delegations to unsigned zones.
+
+ This document describes a method of eliminating the superfluous
+ cryptography present in secure delegations to insecure zones. Using
+ "Opt-In", a zone administrator can choose to remove insecure
+ delegations from the NXT chain. This is accomplished by extending
+ the semantics of the NXT record by using a redundant bit in the type
+ map.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 4]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+3. Protocol Additions
+
+ In RFC 2535, delegation NS RRsets are not signed, but instead are
+ accompanied by a NXT RRset of the same name, and possibly a ("no-
+ key") KEY RR [4] or DS record [7]. The security status of the
+ subzone is determined by the presence or absence of the KEY or DS
+ records, cryptographically proven by the NXT record. Opt-In expands
+ this definition by allowing insecure delegations to exist within an
+ otherwise signed zone without the corresponding NXT record at the
+ delegation's owner name. These insecure delegations are proven
+ insecure by using the covering NXT record.
+
+ 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 cover (or potentially cover) insecure delegation nodes.
+ This tag is indicated by the absence of the NXT bit in the type map.
+ Since the NXT bit in the type map merely indicates the existence of
+ the record itself, this bit is redundant and safe for use as a tag.
+
+ Using Opt-In, the existence or non-existence of insecure delegations
+ is not asserted by the tagged NXT records. This allows for the
+ addition or removal of delegations to unsigned zones without
+ recalculating and resigning the NXT chain. However, Opt-In NXT
+ records still assert the (non)existence of signed RRsets.
+
+ Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records
+ and RFC 2535 NXT records. If a NXT record is not Opt-In, there MUST
+ NOT be any insecure delegations between it and the RRsets indicated
+ by the 'next domain name' in the NXT RDATA. If it is Opt-In, there
+ MUST only be insecure delegations between it and the next node
+ indicated by the 'next domain name' in the NXT RDATA.
+
+ 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.
+
+
+3.1 Server Considerations
+
+ This protocol change dictates a number of changes to the operation of
+ an authoritative server:
+
+ o The server MUST enforce the protocol requirement that ONLY
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 5]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+ insecure delegation nodes may exist between the secure nodes of
+ the zone.
+
+ o The server must be able to retrieve the proper NXT records along
+ with referrals to insecure subzone.
+
+ In the delegation signer proposal, NXT records already must be
+ returned along with referrals to insecure delegations. The primary
+ difference that this proposal introduces is that the appropriate NXT
+ record will have a different owner name.
+
+3.2 Client Considerations
+
+ Opt-In imposes some new requirements on the DNS resolver (caching or
+ otherwise):
+
+ o Resolvers MUST be able to use Opt-In style NXT records to
+ cryptographically prove the validity and security status (as
+ insecure) of a referral:
+
+ * In RFC 2535, this is proven by existence of a verified "no-key"
+ KEY RRset.
+
+ * Using Delegation Signer, this is proven by the existence of a
+ verified NXT record. This NXT record has same name as the
+ delegation RRset and does not have the DS bit set in the type
+ map.
+
+ * Using Opt-In, this is proven by the existence of a verified
+ Opt-In NXT record. This NXT record does not have the NXT bit
+ set in the type map (that is, it is an Opt-In style NXT record)
+ and the name of the delegation RRset is lexicographically
+ between the owner and next names of the NXT record.
+
+ Note that using Opt-In does not substantially change the nature of
+ following referrals within DNSSEC. At every delegation point, the
+ resolver will have cryptographic proof that the subzone is secure
+ or insecure.
+
+ o Resolvers MUST reject as invalid non-NS RRsets that fall within an
+ Opt-In tagged NXT record's span.
+
+ o Caching resolvers must be able to retrieve the appropriate
+ covering Opt-In NXT record when returning referrals that need
+ them. This is only a difference when you consider that the
+ covering NXT record will not have the same name as the delegation
+ RRset itself.
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 6]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+ o The AD bit (as defined by [8]) MUST NOT be set in a response
+ containing an Opt-In tagged NXT record in the authority section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 7]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+4. Benefits
+
+ Using Opt-In allows administrators of large and/or changing
+ delegation-centric zones to minimize the overhead involved in
+ maintaining the security of the zone.
+
+ Opt-In accomplishes this by eliminating the need for both "no-key"
+ KEY (in [4]) and NXT records for insecure delegations. This, in a
+ zone with a large number of delegations to unsigned subzones, can
+ lead to substantial space savings (both in memory and on disk).
+ Additionally, Opt-In allows for the addition or removal of insecure
+ delegations without modifying the NXT record chain. Zones that are
+ frequently updating insecure delegations (e.g., TLDs) can avoid the
+ substantial overhead of modifying and resigning the affected NXT
+ records.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 8]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+5. Example
+
+ Consider the zone EXAMPLE, shown below. This is a zone where all of
+ the NXT records are tagged as Opt-In.
+
+ 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. NS NS.UNSIGNED.EXAMPLE.
+ NS.UNSIGNED.EXAMPLE. A ...
+
+
+ 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 delegation RRset (or a referral) will return
+ both the answer (in the Authority section) and the corresponding Opt-
+ In NXT record to prove that it is not secure.
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 9]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+ Example A.1: Response to query for WWW.UNSECURE.EXAMPLE. A
+
+
+ RCODE=NOERROR
+
+ Answer Section:
+
+ Authority Section:
+ UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
+ SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY
+ SECOND-SECURE.EXAMPLE. SIG NXT ...
+
+ Additional Section:
+ NS.UNSIGNED.EXAMPLE A ...
+ EXAMPLE. KEY ...
+ EXAMPLE. SIG KEY ...
+
+ In the Example A zone, the EXAMPLE. node MAY use either style of NXT
+ record, because there are no insecure delegations 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 NXT records (FIRST-SECURE.EXAMPLE. and SECOND-
+ SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure
+ delegations in the range they define. (NOT-SECURE.EXAMPLE. and
+ UNSIGNED.EXAMPLE., respectively).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 10]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+6. Security Considerations
+
+ Opt-In allows for unsigned delegations. All unsigned names are
+ insecure, and their validity (or existence) can not be
+ cryptographically proven. With Opt-In, a malicious entity is able
+ to: insert, modify, or delete insecure delegation RRsets within a
+ secured zone. For example, if a resolver received the following
+ response from the example zone above:
+
+ Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
+
+ RCODE=NOERROR
+
+ Authority Section:
+ DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
+ EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY
+ EXAMPLE. SIG NXT ...
+
+ Additional Section:
+ EXAMPLE. KEY ...
+ EXAMPLE. SIG KEY ...
+
+ The resolver would have no choice but to believe that the referral to
+ NS.FORGED. is valid.
+
+ While in particular cases, this issue may not present a significant
+ security problem, in general it should not be lightly dismissed. It
+ is strongly RECOMMENDED that Opt-In be used sparingly. In
+ particular, zone signing tools SHOULD NOT default to Opt-In, and MAY
+ choose to not support Opt-In at all.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 11]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+7. IANA Considerations
+
+ None.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 12]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+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 December 26, 2002 [Page 13]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+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] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
+ December 2001.
+
+ [7] Gudmundsson, O., "Delegation Signer Resource Record", draft-
+ ietf-dnsext-delegation-signer-07 (work in progress), March 2002.
+
+ [8] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit",
+ draft-ietf-dnsext-ad-is-secure-05 (work in progress), March
+ 2002.
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 14]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+ 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
+
+
+ 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 December 26, 2002 [Page 15]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+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 only RRsets that may solely exist in the insecure
+ view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and
+ the zone apex NS RRset) MUST be signed and 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 December 26, 2002 [Page 16]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+ 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 December 26, 2002 [Page 17]
+\f
+Internet-Draft DNSSEC Opt-In June 2002
+
+
+Appendix B. Changes from Prior Versions
+
+ Changes from version 01:
+
+ Changed to "delegation only". Strengthened "Security
+ Considerations" section. Added "Server Considerations" and
+ "Client Considerations" sections. Added AD bit requirement.
+
+ Changes from version 00:
+
+ Complete rewrite, altering approach from "views" to tagged NXT
+ records
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 18]
+\f
+Internet-Draft DNSSEC Opt-In June 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires December 26, 2002 [Page 19]
projects / thirdparty / bind9.git / commitdiff
