+++ /dev/null
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: September 1, 2003 M. Larson
- VeriSign
- R. Austein
- ISC
- D. Massey
- USC/ISI
- S. Rose
- NIST
- March 3, 2003
-
-
- Protocol Modifications for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-protocol-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 September 1, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document is part of a family of documents which describes the
- DNS Security Extensions (DNSSEC). The DNS Security Extensions are a
- collection of new resource records and protocol modifications which
- add data origin authentication and data integrity to the DNS. This
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- document describes the DNSSEC protocol modifications. This document
- defines the concept of a signed zone, along with the requirements for
- serving and resolving using DNSSEC. These techniques allow a
- security-aware resolver to authenticate both DNS resource records and
- authoritative DNS error indications.
-
- This document obsoletes RFC 2535 and incorporates changes from all
- updates to RFC 2535.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Background and Related Documents . . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
- 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
- 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
- 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1 Including KEY RRs in a Zone . . . . . . . . . . . . . . . . 6
- 2.2 Including SIG RRs in a Zone . . . . . . . . . . . . . . . . 7
- 2.3 Including NXT RRs in a Zone . . . . . . . . . . . . . . . . 8
- 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
- 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
- 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8
- 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 3.1 Including SIG RRs in a Response . . . . . . . . . . . . . . 10
- 3.2 Including KEY RRs In a Response . . . . . . . . . . . . . . 11
- 3.3 Including NXT RRs In a Response . . . . . . . . . . . . . . 11
- 3.3.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12
- 3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches . 12
- 3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13
- 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13
- 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13
- 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 15
- 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 15
- 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16
- 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 23
- 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24
- 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25
- 5.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26
- 5.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 27
- 5.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 27
- 5.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28
- 5.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30
- 5.2.4 Authenticating A Wildcard Expanded RRset Positive Response . 31
- 5.3 Authenticated Denial of Existence . . . . . . . . . . . . . 31
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- 5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32
- 5.4.1 Example of Re-Constructing the Original Owner Name . . . . . 32
- 5.4.2 Examples of Authenticating a Response . . . . . . . . . . . 33
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 35
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
- Normative References . . . . . . . . . . . . . . . . . . . . 37
- Informative References . . . . . . . . . . . . . . . . . . . 38
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
- A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 40
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) modify several aspects of the
- DNS protocol. Section 2 defines the concept of a signed zone and
- lists the requirements for zone signing. Section 3 describes the
- modifications to authoritative name server behavior necessary to
- handle signed zones. Section 4 describes the behavior of entities
- which include security-aware resolver functions Finally, Section 5
- defines how to use DNSSEC RRs to authenticate a response.
-
-1.1 Background and Related Documents
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in RFC1034 [1] and RFC1035 [2].
-
- This document is part of a family of documents which define the DNS
- security extensions (DNSSEC). The DNS Security Extensions are a
- collection of new resource records and protocol modifications which
- add data origin authentication and data integrity to the DNS. An
- introduction to DNSSEC and definition of common terms can be found in
- [9]. A definition of the DNSSEC resource records can be found in
- [10]. This document defines the DNSSEC protocol modifications.
-
-1.2 Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119. [4].
-
-1.3 Editors' Notes
-
-1.3.1 Open Technical Issues
-
- Use of NXT RRs throughout this document set will have to be modified
- if DNSSEC-Opt-In [11] becomes part of DNSSEC. The use of the NXT
- record requires input from the working group. This text describes
- the NXT record as it was defined in RFC 2535, and substantial
- portions of this document would need to be updated to incorporate
- opt-in. The updates will be made if the WG adopts opt-in.
-
- Use of the AD bit requires input from the working group. Since the
- AD bit usage is not resolved, this text attempts to capture current
- ideas and drafts, but further input from the working group is
- required.
-
-1.3.2 Technical Changes or Corrections
-
- Please report technical corrections to dnssec-editors@east.isi.edu.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- To assist the editors, please indicate the text in error and point
- out the RFC that defines the correct behavior. For a technical
- change where no RFC that defines the correct behavior, or if there's
- more than one applicable RFC and the definitions conflict, please
- post the issue to namedroppers.
-
- An example correction to dnssec-editors might be: Page X says
- "DNSSEC RRs SHOULD be automatically returned in responses." This was
- true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
- DNSSEC RR types MUST NOT be included in responses unless the resolver
- indicated support for DNSSEC.
-
-1.3.3 Typos and Minor Corrections
-
- Please report any typos corrections to dnssec-editors@east.isi.edu.
- To assist the editors, please provide enough context for us to find
- the incorrect text quickly.
-
- An example message to dnssec-editors might be: page X says "the
- DNSSEC standard has been in development for over 1 years". It
- should read "over 10 years".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-2. Zone Signing
-
- DNSSEC defines the concept of a signed zone. A signed zone includes
- KEY, SIG, NXT and (optionally) DS records according to the rules
- specified in Section 2.1, Section 2.2, Section 2.3 and Section 2.4,
- respectively. Any zone which does not include these records
- according to the rules in this section must be considered unsigned.
-
- Editors' note: Should this be "MUST be considered unsigned"?
-
- DNSSEC requires a change to the definition of the CNAME resource
- record. Section 2.5 changes the CNAME RR to allow SIG and NXT RRs to
- appear at the same owner name as a CNAME RR.
-
- Section 2.6 shows a sample signed zone.
-
-2.1 Including KEY RRs in a Zone
-
- Editors' note: Unresolved inconsistency between paragraphs in this
- section, regarding non-zone KEY RRs at the zone apex. SHOULD NOT,
- or MUST NOT?
-
- To sign a zone, the zone's administrator generates one or more
- public/private key pairs and uses the private key(s) to sign
- authoritative RRsets in the zone. For each private key used to
- create SIG RRs, there SHOULD be a corresponding KEY RR stored at the
- zone apex. All KEY RRs at the zone apex MUST be zone keys. (A zone
- key KEY RR has the Zone Key bit of the Flags RDATA field set to one.
- See Section 2.1.1 of [10].) Zone key KEY RRs MUST appear only at the
- zone apex.
-
- A signed zone MUST have at least one zone key KEY RR in its apex KEY
- RRset. The KEY RRset at the zone apex MUST be self-signed by at
- least one private key whose corresponding public key is a zone key
- stored in the apex KEY RRset.
-
- Editors' note: The requirement listed in this paragraph may not be
- necessary anymore, since the KEY RRset is self-signed anyway
- (because the whole zone is signed). This is probably a pre-DS
- relic, but we spotted this a few hours before the I-D deadline and
- were too chicken to remove it on such short notice....
-
- Other public keys associated with other DNS operations can be stored
- in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs
- MUST NOT appear at delegation names. Non-zone key KEY RRs also
- SHOULD NOT appear at the zone apex, because large KEY RRsets add
- processing time at resolvers. Non-zone key KEY RRs MAY appear at any
- other name in the zone.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-2.2 Including SIG RRs in a Zone
-
- For each authoritative RRset in the zone (which excludes NS RRsets at
- delegation points and glue RRsets), there MUST be at least one SIG
- record that meets all of the following requirements:
-
- o The SIG owner name is equal to the RRset owner name;
-
- o The SIG class is equal to the RRset class;
-
- o The SIG Type Covered field is equal to the RRset type;
-
- o The SIG Original TTL field is equal to the TTL of the RRset;
-
- o The SIG RR's TTL is equal to the TTL of the RRset;
-
- o The SIG Labels field is equal to the number of labels in the RRset
- owner name, not counting the null root label or any wildcard
- label;
-
- o The SIG Signer's Name field is equal to the name of the zone
- containing the RRset; and
-
- o The SIG Algorithm, Signer's Name, and Key Tag fields identify a
- zone key KEY record at the zone apex.
-
- The process for constructing the SIG RR for a given RRset is
- described in [10]. An RRset MAY have multiple SIG RRs associated
- with it.
-
- A SIG RR itself MUST NOT be signed, since signing a SIG RRset would
- add no value and would create an unterminated dependency loop in the
- signing process.
-
- The NS RRset which appears at the zone apex name MUST be signed, but
- the NS RRsets which appear at delegation points (that is, the NS
- RRsets in the parent zone which delegate the name to the child zone's
- name servers) MUST NOT be signed. Glue address RRsets associated
- with delegations MUST NOT be signed.
-
- The difference between the set of owner names which require SIG
- records and the set of owner names which require NXT records is
- subtle and worth highlighting. SIG records are present at the owner
- names of all authoritative RRsets. NXT records are present at the
- owner names of all names for which the signed zone is authoritative
- and also at the owner names of delegations from the signed zone to
- its children. Neither NXT nor SIG records are present (in the parent
- zone) at the owner names of glue address RRsets. Note, however, that
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- this distinction is for the most part only visible during the zone
- signing process, because NXT RRsets are authoritative data, and
- therefore are signed, thus any owner name which has an NXT RRset will
- have SIG RRs as well in the signed zone.
-
-2.3 Including NXT RRs in a Zone
-
- Each owner name in the zone MUST have an NXT resource record, except
- for the owner names of any glue address RRsets. The process for
- constructing the NXT RR for a given name is described in [10].
-
-2.4 Including DS RRs in a Zone
-
- The DS resource record establishes authentication chains between DNS
- zones. A DS RRset SHOULD be present at a delegation point when the
- child zone is signed. The DS RRset MAY contain multiple records,
- each referencing a key used by the child zone to sign its apex KEY
- RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT
- appear at non-delegation points nor at a zone's apex.
-
- A DS RR SHOULD point to a KEY RR which is present in the child's apex
- KEY RRset, and the child's apex KEY RRset SHOULD be signed by the
- corresponding private key.
-
- Construction of a DS RR requires knowledge of the corresponding KEY
- RR in the child zone, which implies communication between the child
- and parent zones. This communication is an operational matter not
- covered by this document.
-
-2.5 Changes to the CNAME Resource Record.
-
- If a CNAME RRset is present at a name in a signed zone, appropriate
- SIG and NXT RRsets are REQUIRED at that name. Other types MUST NOT
- be present at that name.
-
- This is a modification to the original CNAME definition given in [1].
- The original definition of the CNAME RR did not allow any other types
- to co-exist with a CNAME record, but a signed zone requires NXT and
- SIG RRsets for every authoritative name. To resolve this conflict,
- the definition of the CNAME resource record is hereby modified to
- allow for the co-existence of NXT and SIG RRsets.
-
-2.6 Example of a Secure Zone
-
- {{secure zone here}}
-
- Editors' note: Zone file example deferred pending hackery to add
- zone files in a format usable by xml2rfc. Goal here is to show a
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- (small) complete signed zone.
-
- The apex KEY set includes two KEY RRs, and the KEY RDATA Flags
- indicate that each of these KEY RRs is a zone key. The first zone
- KEY is used to sign the apex KEY RRset, and a DS record for this key
- is provided to the parent zone. The second zone KEY is used to sign
- all the other RRsets in the zone. A non-zone KEY RR is also stored
- at "host1.example.com"; this KEY might be used by SIG(0) to
- authenticate transactions from this host.
-
- The zone includes a wildcard entry "*.a.example.com". Note that the
- "*.a.example.com" name is used in constructing NXT chains, and that
- the SIG covering the "*.a.example.com" MX RRset has a label count of
- 3.
-
- The zone also includes two delegations. The delegation to
- "insecure.example.com" includes an NS RRset, glue address records,
- and an NXT RR, but note that only the NXT RRset is signed. The
- "secure.example.com" delegation provides a DS RR, and note that only
- NXT and DS RRsets are signed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-3. Serving
-
- This section describes the behavior of a security-aware authoritative
- name server. A security-aware authoritative name server MUST support
- the EDNS0 [6] message size extension, MUST support a message size of
- at least 1220 octets, and SHOULD support a message size of 4000
- octets [8]. Since functions specific to security-aware recursive
- name servers included components of both resolving and serving,
- issues specific to security-aware recursive name servers are
- described in Section 4.
-
- Upon receiving a relevant query which has the EDNS [6] OPT pseudo-RR
- DO [7] bit set to one, a security-aware authoritative name server for
- a signed zone MUST include additional SIG, NXT, and DS RRs according
- to the following rules:
-
- o SIG RRs which can be used to authenticate a response MUST be
- included in the response automatically according to the rules in
- Section 3.1;
-
- o NXT RRs which can be used to provide authenticated denial of
- existence MUST be included in the response automatically according
- to the rules in Section 3.3;
-
- o Either DS RRs or an NXT RR proving that no DS RRs exist MUST be
- included in referrals automatically according to the rules in
- Section 3.4.
-
- DNSSEC does not change the DNS zone transfer protocol. Zone transfer
- requirements are reviewed in Section 3.6.
-
- A security-aware name server which receives a DNS query which does
- not include the EDNS OPT pseudo-RR, or which has the DO bit set to
- zero, MUST treat the SIG, KEY, and NXT RRs as it would any other
- RRset, and MUST NOT perform any of the additional processing
- described above. Since the DS RR type has the peculiar property of
- only existing in the parent zone at delegation points, DS RRs always
- require some special processing, as described in Section 3.5.
-
-3.1 Including SIG RRs in a Response
-
- When a query has the DO bit set to one, the authoritative name server
- SHOULD attempt to send SIG RRs which can be used to authenticate the
- RRsets in the response. Inclusion of SIG RRs in a response is
- subject to the following rules:
-
- o When a signed RRset is placed in the Answer section, its SIG RRs
- are also placed in the Answer section. The SIG RRs have a higher
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- priority for inclusion than any other RRsets which may need to be
- included. If space does not permit the inclusion of these SIG
- RRs, the response MUST be considered truncated, and the TC bit
- MUST be set.
-
- o When a signed RRset is placed in the Authority section, its SIG
- RRs are also placed in the Authority section. The SIG RRs have a
- higher priority for inclusion than any other RRsets that may need
- to be included. If space does not permit the inclusion of these
- SIG RRs, the response MUST be considered truncated, and the TC bit
- MUST be set.
-
- o When a signed RRset is placed in the Additional section, its SIG
- RRs are also placed in the Additional section. If space does not
- permit the inclusion of these SIG RRs, the response MUST NOT be
- considered truncated just because these SIG RRs didn't fit.
-
-
-3.2 Including KEY RRs In a Response
-
- When a query has the DO bit set to one and requests the SOA or NS RRs
- at the apex of a signed zone, then a security-aware authoritative
- name server for that zone SHOULD return the KEY RRset with the same
- name in the Additional section. If Additional section processing
- results in more data than will fit in the response message, address
- glue RRs have higher priority than KEY RRs. SIG RR(s) associated
- with the KEY RRset SHOULD also be included in the Additional section
- (see Section 3.1).
-
- Editors' note: Didn't the WG decide that DS RR removes the need
- for Additional section processing for KEY RRs? If so, this
- subsection should be deleted.
-
-
-3.3 Including NXT RRs In a Response
-
- Editors' note: This whole section uses the phrase "query name
- exists", which is somewhat ambiguous when discussing internal
- nodes with no RRs. We are reasonably certain that, as used here,
- the phrase only refers to names which are the owner name for least
- one RR. Better phrasing needed.
-
- When a query has the DO bit set to one, security-aware authoritative
- name servers for a signed zone MUST include NXT RRs in each of the
- following cases:
-
- Case 1: The query name exists, but the requested RR type does not
- exist.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- Case 2: The query name does not exist, and no wildcard can be
- expanded to answer the query.
-
- Case 3: The query name does not exist, but a wildcard can be expanded
- to positively answer the query.
-
- Note that, in each case, a set of NXT RRs is included to provide
- authenticated denial of existence.
-
- NXT RRs are also included in a referral response when no DS RR is
- present; in this case, the NXT RR proves that no DS RR exists for the
- delegation. Referrals are discussed in more detail in Section 3.4.
-
-3.3.1 Case 1: Query Name Exists, but RR Type Not Present
-
- If the query name exists but the requested RR type is not present at
- the name, then the NXT RR associated with the query name MUST be
- included in the Authority section. Any SIG(s) associated with the
- NXT RRset are also included in the Authority section (see Section
- 3.1) If space does not permit the inclusion of the NXT RR (or its
- associate SIG RRs), the response MUST be considered truncated and the
- TC bit MUST be set.
-
- Note that, since the query name exists, no wildcard expansion applies
- to this query, and a single NXT RR suffices to prove the requested
- type does not exist.
-
-3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches
-
- If the query name does not exist, and no wildcard expansion matches
- the query, then the Authority section of the response MUST include
- the following NXT RRs:
-
- o An NXT RR proving that there was no exact match for the name; and
-
- o An NXT RR proving that there was no wildcard which would have
- matched the query.
-
- If space does not permit the inclusion of these NXT RRs, the response
- MUST be considered truncated, and the TC bit MUST be set. Any SIG(s)
- associated with the NXT RRsets MUST also be included in the Authority
- section (see Section 3.1).
-
- Editors' note: Should lack of space to include the SIGs cause the
- packet to be considered truncated?
-
- Appendix A provides an algorithm which computes the appropriate NXT
- RRs to prove that no wildcard matches a given query name.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches
-
- If the query name does not exist, but a wildcard expansion can be
- used to return a positive match to the query, then the wildcard-
- expanded answer and any SIG RRs associated with the wildcard RR MUST
- be returned in the Answer section. The Authority section of the
- response MUST include the following NXT RRs:
-
- o An NXT RR which proves that there were no exact matches for the
- QNAME and QTYPE; and
-
- o An NXT RR which proves that there are no closer wildcard entries
- which could have been expanded to match the query.
-
- If space does not permit inclusion of these NXT RRs, the response
- MUST be considered truncated, and the TC bit MUST be set. Any SIG
- RRs associated with the NXT RRsets MUST also be included in the
- response.
-
- Editors' note: Should lack of space to include the SIGs cause the
- packet to be considered truncated?
-
- Appendix A provides an algorithm which computes the appropriate NXT
- RRs to prove that no closer wildcard matches the query name.
-
-3.4 Including DS RRs In a Response
-
- When a query has the DO bit set to one, and a DS RR exists at the
- query name, an authoritative security-aware name server returning a
- referral for the delegation MUST include both the NS RRset and also
- the DS RRset and its associated SIG RR(s). The NS RRset MUST be
- placed before the DS RRset and its associated SIG RRs.
-
- When a query has the DO bit set to one, and no DS RR exists at the
- query name, an authoritative security-aware name server returning a
- referral for the delegation MUST include both the NS RRset and also
- the NXT RR and associated SIG RR(s) which proves that the DS RRset
- does not exist. The NS RRset MUST be placed before the NXT RRset and
- its associated SIG RR(s).
-
- This increases the size of referral messages, and may cause some or
- all glue RRs to be omitted. If space does not permit the inclusion
- of the DS or NXT RRset and associated SIG RRs, the response MUST be
- considered truncated, and the TC bit MUST be set.
-
-3.5 Responding to Queries for DS RRs
-
- The DS record is the first resource record type which appears only on
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 13]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- the parent zone's side of a zone cut. In other words, the DS record
- for the delegation of "example.com" is only stored in the "com" zone.
- This introduces novel name server behavior, since the name server for
- the child zone is authoritative for the name by the normal DNS rules
- but the child zone does not contain the DS RR. A name server's
- response to a DS query depends on whether the name server is
- authoritative for the parent zone, the child zone, or both, as
- described below.
-
- If a name server is authoritative for the parent zone, and receives a
- query for the DS record at the delegated name, then the name server
- MUST return the DS RRset from the parent zone. This rule applies
- regardless of whether or not the name server is also authoritative
- for the child zone.
-
- If the name server is authoritative for the child zone, is not
- authoritative for the parent zone, and receives a query for the DS
- record at the delegated name, there is no obvious response, because
- the child zone is not authoritative for the DS record at the child
- zone's apex, and the authoritative DS RR is only stored at the
- parent.
-
- If the name server allows recursion, and the RD bit is set in the
- query, the name server MAY perform recursion to find the DS record
- for the delegated name from the parent zone, and MAY return the DS
- record from its cache. In this case, the AA bit MUST NOT be set in
- the response.
-
- If the name server does not perform recursion to find the DS RR, the
- name server MUST reply with:
-
- RCODE: NOERROR
- AA bit: set
- Answer Section: Empty
- Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
- In other words, a name server which is authoritative for the child
- zone but not for the parent zone answers as if the DS record does not
- exist. Note that security-aware resolvers will query the parent zone
- at delegation points, and thus will not be affected by this behavior.
-
- For example, suppose that "example.com" is a delegation point, and a
- name server receives a query for the "example.com" DS RRset.
-
- o If the name server is authoritative for "com", the name server
- MUST reply with the "example.com" DS RRset from the "com" zone.
-
- o If the name server is authoritative for "example.com", is not
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 14]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- authoritative for "com", and the RD bit is set to one in the
- query, the name server MAY perform recursion to find the
- "example.com" DS record. If the name server does not use
- recursion to obtain the DS RR, the name server MUST reply as
- though the DS RR did not exist:
-
- RCODE: NOERROR
- AA bit: set
- Answer Section: Empty
- Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
-
-3.6 Responding to Queries for Type AXFR or IXFR
-
- DNSSEC does not change the DNS zone transfer process. A signed zone
- will contain SIG, KEY, NXT, and DS resource records, but these
- records have no special meaning with respect to a zone transfer
- operation, and these RRs are treated as any other resource record
- type.
-
- An authoritative name server is not required to verify that a zone is
- properly signed before sending or accepting a zone transfer.
- However, an authoritative name server MAY choose to reject the entire
- zone transfer if the zone fails meets any of the signing requirements
- described in Section Section 2. The primary objective of a zone
- transfer to ensure that all authoritative name servers have identical
- copies of the zone. An authoritative name server which chooses to
- perform its own zone validation MUST NOT selectively reject some RRs
- and accept others.
-
- Note that the DS RR appears only in the parental side of a
- delegation, and is authoritative data in the parent zone. For
- example, the DS RR for "example.com" is stored in the "com" zone (the
- parent zone) rather than in the "example.com" zone (the child zone).
- As with any other authoritative RRset, the "example.com" DS RR MUST
- be included the "com" zone transfer.
-
- Note that authoritative NXT RRs appear in both the parent and child
- zones at a delegated name, and that the NXT RRs for the delegated
- name in the parent and child zones are never identical to each other.
- As with any other authoritative RRset, the parental NXT RR at a
- delegated name MUST be included zone transfers of the parent zone,
- while the NXT at the zone apex of the child zone MUST be included in
- zone transfers of the child zone.
-
-3.7 Setting the AD and CD Bits in a Response
-
- Editors' note: This section seems a little lost here. Perhaps we
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 15]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- should rearrange the section ordering slightly, or provide a
- pointer to this subsection at the beginning of Section 3.
-
- DNSSEC allocates two new bits in the DNS message header: The CD
- (Checking Disabled) bit and the AD (Authentic Data) bit.
-
- The CD bit is set in query messages by the resolver, and MUST be
- copied into the response. If the CD bit is set to one, it indicates
- that the resolver is willing to perform authentication, and thus that
- the name server need not perform authentication on the RRsets in the
- response.
-
- Regardless of the setting of the CD bit, the name server MAY choose
- whether or not to perform authentication according to the local name
- server policy. The CD bit MAY be used in constructing the local name
- server policy. If local name server policy does perform
- authentication, any RRsets rejected by the local authentication
- policy MUST NOT be returned in a response (regardless of the CD bit).
-
- The AD bit is set by name servers, and indicates the data in the
- response has been authenticated by the name server, according to the
- local name server policy. The AD bit MUST NOT be set on a response
- unless all of the RRsets in the Answer and Authority sections have
- met the name server's local authentication policy. A resolver MUST
- NOT trust the AD bit unless it communicates with the name server over
- a secure transport mechanism and is explicitly configured to trust
- the name server's policy.
-
-3.8 Example DNSSEC Responses
-
- The examples in this section use the following example zone to
- demonstrate the formation of replies by an authoritative name server.
- The zone has two name servers, a single child, and a wildcard MX RR.
- The zone is completely signed and has a full NXT chain.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 16]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- example.com. SOA (...)
- SIG SOA ...
- NS a.example.com.
- NS b.example.com.
- SIG NS ...
- MX 10 a.example.com
- SIG MX ...
- KEY ...
- SIG KEY ...
- NXT *.example.com.
- * MX 10 a.example.com.
- SIG MX ...
- NXT a.example.com.
- a A 10.10.10.1
- SIG A ...
- NXT b.example.com.
- b A 10.10.10.2
- SIG A ...
- NXT c.example.com.
- c CNAME a.example.com.
- SIG CNAME
- NXT sub.example.com.
- sub NS ns.sub.example.com.
- SIG NS
- DS ...
- SIG DS
- NXT *.example.com.
- ns.sub A 10.10.10.3
- sub-nosig NS ns.sub-nosig.example.com.
- NXT example.com.
- ns.sub-nosig A 10.10.10.4
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 17]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- A query to the authoritative name server for this zone for
- QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce:
-
- Flags: QR=1, AA=1, RCODE=0 (NOERROR)
- EDNS: DO=1, size=4000
- QUERY:
- c.example.com. IN A
- ANSWER:
- c.example.com. IN A a.example.com
- IN SIG CNAME
- a.example.com. IN A 10.10.10.1
- IN SIG A
- AUTHORITY:
- example.com. IN NS a.example.com.
- IN NS b.example.com.
- IN SIG NS ...
- ADDITIONAL:
- a.example.com. IN A 10.10.10.1
- IN SIG A ...
- b.example.com. IN A 10.10.10.2
- IN SIG A ...
- example.com. IN KEY ...
- IN SIG KEY ...
-
- A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would
- results in a referral to a signed zone. The resolver can determine
- that "sub.example.com" is signed because of the presence of the DS RR
- with the hash of the "sub.example.com" zone key.
-
- Flags: QR=1, AA=1, RCODE=0 (NOERROR)
- EDNS: DO=1, size=4000
- QUERY:
- www.sub.example.com. IN A
- ANSWER:
- ;; empty
- AUTHORITY:
- sub.example.com. IN NS ns.sub.example.com.
- IN DS ...
- IN SIG DS ...
- ADDITIONAL:
- ns.sub.example.com. IN A 10.10.10.3
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 18]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A
- would result in a referral to an unsigned zone. The resolver knows
- not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS
- bit in the NXT RR bitmap in the referral is not set. Even if DNSSEC
- RRs are present in responses from "sub-nosig.example.com" name
- servers, the resolver will not be able to construct a authentication
- chain, since there is a break between "sub-nosig.example.com" and its
- delegating parent zone.
-
- Flags: QR=1, AA=1, RCODE=0 (NOERROR)
- EDNS: DO=1, size=4000
- QUERY:
- www.sub-nosig.example.com. IN A
- ANSWER:
- ;; empty
- AUTHORITY:
- sub-nosig.example.com. IN NS ns.sub-nosig.example.com.
- IN NXT ;; (DS bit not set)
- IN SIG NXT ...
- ADDITIONAL:
- ns.sub-nosig.example.com. IN A 10.10.10.4
-
- A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name
- error, because the name does not exist and is not covered by wildcard
- expansion. Therefore, the name server must present proof that the
- name does not exist, and that no wildcard expansion is present which
- could have been used to answer the query.
-
- Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN)
- EDNS: DO=1, size=4000
- QUERY:
- f.example.com. IN A
- ANSWER:
- ;; empty
- AUTHORITY:
- example.com. IN SOA ...
- IN SIG SOA ...
- c.example.com. IN NXT sub.example.com. ...
- IN SIG NXT ...
- *.example.com. IN NXT a.example.com. ...
- IN SIG NXT ...
- ADDITIONAL:
- example.com. IN KEY ...
- IN SIG KEY ...
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 19]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX
- RR synthesized via wildcard expansion. The name server must prove
- that no exact match exists.
-
- Flags: QR=1, AA=1, RCODE=0 (NOERROR)
- EDNS: DO=1, size=4000
- QUERY:
- f.example.com. IN MX
- ANSWER:
- f.example.com. IN MX 10 a.example.com.
- IN SIG MX ...
- AUTHORITY:
- example.com. IN NS a.example.com.
- IN NS b.example.com.
- IN SIG NS ...
- c.example.com. IN NXT sub.example.com.
- IN SIG NXT ...
- ADDITIONAL:
- a.example.com. IN A 10.10.10.1
- IN SIG A ...
- b.example.com. IN A 10.10.10.2
- IN SIG A ...
- example.com. IN KEY ...
- IN SIG KEY ...
-
- If these responses came from a recursive name server which had all of
- the necessary RRsets in its cache instead of from an authoritative
- server, the only differences would be the TTLs and the header flags.
- The AA bit would not be set, and the AD bit would be set if (and only
- if) all the RRsets in a response passed the security policy checks of
- the recursive name server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 20]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-4. Resolving
-
- Editors' note: This section is still very rough, and some of the
- text here duplicates text from other portions of this document.
- This needs to be fixed (one way or another) during final editing.
- Suggestions for better text would be welcome.
-
- This section describes the behavior of entities which include
- security-aware resolver functions. In many cases such functions will
- be part of a security-aware recursive name server, but a stand-alone
- security-aware resolver has many of the same requirements. Functions
- specific to security-aware recursive name servers are described in a
- separate subsection.
-
- A security-aware resolver MUST include an EDNS [6] OPT pseudo-RR with
- the DO [7] bit set to one when sending queries.
-
- A security-aware resolver MUST support a message size of at least
- 1220 octets, SHOULD support a message size of 4000 octets, and MUST
- advertise the supported message size using the "sender's UDP payload
- size" field in the EDNS OPT pseudo-RR. A security-aware resolver
- MUST handle fragmented UDP packets correctly regardless of whether
- any such fragmented packets were received via IPv4 or IPv6. Please
- see [8] for discussion of these requirements.
-
- A security-aware resolver MUST support the signature verification
- mechanisms described in Section 5, and MUST apply them to every
- received response except when:
-
- o The security-aware resolver is part of a security-aware recursive
- name server, and the response is the result of recursion on behalf
- of a query received with the CD bit set;
-
- o The response is the result of a query generated directly via some
- form of application interface which instructed the security-aware
- resolver not to perform validation for this query; or
-
- o Validation for this query has been disabled by local policy.
-
- A security-aware resolver's support for signature verification MUST
- include support for verification of wildcard owner names.
-
- A security-aware resolver MUST attempt to retrieve missing DS, KEY,
- or SIG RRs via explicit queries if the resolver needs these RRs in
- order to perform signature verification.
-
- A security-aware resolver MUST attempt to retrieve missing a NXT RR
- which the resolver needs to authenticate a NODATA response. In
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 21]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- general it is not possible for a resolver to retrieve missing NXT
- RRs, since the resolver will have no way of knowing the owner name of
- the missing NXT RR, but in the specific case of a NODATA response,
- the resolver does know the name of the missing NXT RR, and must
- therefore attempt to retrieve it.
-
- A security-aware resolver MUST be able to determine whether or not it
- should expect a particular RRset to be signed. More precisely, a
- security-aware resolver must be able to distinguish between three
- cases:
-
- 1. An RRset for which the resolver is able to build a chain of
- signed KEY and DS RRs from a trusted starting point to the RRset.
- In this case, the RRset should be signed, and is subject to
- signature validation as described above.
-
- 2. An RRset for which the resolver knows that it has no chain of
- signed KEY and DS RRs from any trusted starting point to the
- RRset. This can occur when the target RRset lies in an unsigned
- zone or in a descendent of an unsigned zone. In this case, the
- RRset may or may not be signed, but the resolver will not be able
- to verify the signature.
-
- 3. An RRset for which the resolver is not able to determine whether
- or not the RRset should be signed, because the resolver is not
- able to obtain the necessary DNSSEC RRs. This can occur due when
- the security-aware resolver is not able to contact security-aware
- name servers for the relevant zones.
-
- A security-aware resolver MUST be capable of being preconfigured with
- at least one trusted public key, and SHOULD be capable of being
- preconfigured with multiple trusted public keys. Since a security-
- aware resolver will not be able to validate signatures without such a
- preconfigured trusted key, the resolver SHOULD have some reasonably
- robust mechanism for obtaining such keys when it boots.
-
- Editors' note: Should support for multiple public keys be a MUST
- rather than a SHOULD?
-
- A security-aware resolver SHOULD cache each response as a single
- atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
- single atomic entry containing the entire answer, including the named
- RRset and any associated DNSSEC RRs. The resolver SHOULD discard the
- entire atomic entry when any of the RRs contained in it expire.
-
- Editors' note: This is implementation advice which came out of
- discussions at various workshops and investigations into possible
- implementation issues with the (as yet unsettled) opt-in proposal.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 22]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- All of this advice has been discussed in WG meetings, and as far
- as the editors know these recommendations are not controversial,
- but it is up to the WG to decide whether this sort of
- implementation advice belongs in this document.
-
-
-4.1 Recursive Name Servers
-
- As explained in [9], a security-aware recursive name server is an
- entity which acts in both the security-aware name server and
- security-aware resolver roles. This section uses the terms "name
- server side" and "resolver side" to refer to the code within a
- security-aware recursive name server which implements the security-
- aware name server role and the code which implements the security-
- aware resolver role, respectively.
-
- The resolver side of a security-aware recursive name server MUST set
- the DO bit when sending requests, regardless of the state of the DO
- bit in the initiating request received by the name server side. If
- the initiating request does not have the DO bit set, the name server
- side MUST remove any DNSSEC RRs from the response sent to the
- initiating resolver, but the resolver side MUST follow the usual
- rules for caching which would apply to any security-aware resolver.
-
- A security-aware recursive name server SHOULD NOT attempt to answer a
- query by piecing together cached data it received in response to
- previous queries that requested different QNAMEs, QTYPEs, or
- QCLASSes. A security-aware recursive name server SHOULD NOT use NXT
- RRs from one negative response to synthesize a response for a
- different query. A security-aware recursive name server SHOULD NOT
- use a previous wildcard expansion to generate a response to a
- different query.
-
- Editors' note: Should any of the SHOULD NOTs in this paragraph be
- MUST NOTs instead?
-
- The name server side of a security-aware recursive name server MUST
- pass the sense of the CD bit to the resolver side along with the rest
- of an initiating query, so that the resolver side will know whether
- whether or not it is required to verify the response data it returns
- to the name server side.
-
- Editors' note: What should a security-aware recursive name server
- do if it receives a query with CD=1 and DO=0?
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 23]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-4.2 Stub resolvers
-
- A security-aware stub resolver MUST include an EDNS [6] OPT pseudo-RR
- with the DO [7] bit set to one when sending queries.
-
- A security-aware stub resolver MUST support a message size of at
- least 1220 octets, SHOULD support a message size of 4000 octets, and
- MUST advertise the supported message size using the "sender's UDP
- payload size" field in the EDNS OPT pseudo-RR. A security-aware stub
- resolver MUST handle fragmented UDP packets correctly regardless of
- whether any such fragmented packets were received via IPv4 or IPv6.
- Please see [8] for discussion of these requirements.
-
- A security-aware stub resolver MUST support the DNSSEC RR types, at
- least to the extent of not mishandling responses just because they
- contain DNSSEC RRs. A security-aware stub resolver MAY include the
- DNSSEC RRs returned by a security-aware recursive name server as part
- of the data that it the stub resolver hands back to the application
- which invoked it, but is not required to do so.
-
- A security-aware stub resolver SHOULD NOT set the CD bit when sending
- queries, since, by definition, a security-aware stub resolver does
- not validate signatures and thus depends on the security-aware
- recursive name server to perform validation on its behalf.
-
- Editors' note: Should this SHOULD NOT be a MUST NOT?
-
- A security-aware stub resolver MUST NOT place any reliance on
- signature validation allegedly performed on its behalf except when
- the security-aware stub resolver obtained the data in question from a
- trusted security-aware recursive name server via a secure channel.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 24]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-5. Authenticating DNS Responses
-
- In order to use DNSSEC RRs for authentication, a security-aware
- resolver requires preconfigured knowledge of at least one
- authenticated KEY RR. The process for obtaining and authenticating
- this initial KEY RR is achieved via some external mechanism. For
- example, a resolver could use some off-line authenticated exchange to
- obtain a zone's KEY RR or obtain a DS RR that identifies and
- authenticates a zone's KEY RR. The remainder of this section assumes
- that the resolver has somehow obtained an initial set of
- authenticated KEY RRs.
-
- An initial KEY RR can be used to authenticate a zone's apex KEY
- RRset. To authenticate an apex KEY RRset using an initial key, the
- resolver MUST:
-
- 1. Verify that the initial KEY RR appears in the apex KEY RRset, and
- verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7)
- set to one.
-
- 2. Verify that there is some SIG RR which covers the apex KEY RRset,
- and that the combination of the SIG RR and the initial KEY RR
- authenticates the KEY RRset. The process for using a SIG RR to
- authenticate an RRset is described in Section 5.2.
-
- Once the resolver has authenticated the apex KEY RRset using an
- initial KEY RR, delegations from that zone can be authenticated using
- DS RRs. This allows a resolver to start from an initial key, and use
- DS RRsets to proceed recursively down the DNS tree obtaining other
- apex KEY RRsets. If the resolver were preconfigured with a root KEY
- RR, and if every delegation had a DS RR associated with it, then the
- resolver could obtain any apex KEY RRset. The process of using DS
- RRs to authenticate referrals is described in Section 5.1.
-
- Once the resolver has authenticated a zone's apex KEY RRset, Section
- 5.2 shows how the resolver can use KEY RRs in the apex KEY RRset and
- SIG RRs from the zone to authenticate any other RRsets in the zone.
- Section 5.3 shows how the resolver can use authenticated NXT RRsets
- from the zone to prove that an RRset is not present in the zone.
-
- When a resolver indicates support for DNSSEC, a security-aware name
- server should attempt to provide the necessary KEY, SIG, NXT, and DS
- RRsets in a response (see Section 3). However, a security-aware
- resolver may still receive a response which that lacks the
- appropriate DNSSEC RRs, whether due to configuration issues such as a
- security-oblivious recursive name server which accidently interfere
- with DNSSEC RRs or due to a deliberate attack in which an adversary
- forges a response, strips DNSSEC RRs from a response, or modifies a
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 25]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- query so that DNSSEC RRs appear not to be requested. The absence of
- DNSSEC data in a response MUST NOT by itself be taken as an
- indication that no authentication information exists.
-
- A resolver SHOULD expect authentication information from signed
- zones. A resolver SHOULD believe that a zone is signed if the
- resolver has been configured with public key information for the
- zone, or if the zone's parent is signed and the delegation from the
- parent contains a DS RRset.
-
-5.1 Authenticating Referrals
-
- Once the apex KEY RRset for a signed parent zone has been
- authenticated, DS RRsets can be used to authenticate the delegation
- to a signed child zone. A DS RR identifies a KEY RR in the child
- zone's apex KEY RRset, and contains a cryptographic digest of the
- child zone's KEY RR. A strong cryptographic digest algorithm ensures
- that an adversary can not easily generate a KEY RR that matches the
- digest. Thus, authenticating the digest allows a resolver to
- authenticate the matching KEY RR. The resolver can then use this
- child KEY RR to authenticate the entire child apex KEY RRset.
-
- Given a DS RR for a delegation, the child zone's apex KEY RRset can
- be authenticated if all of the following hold:
-
- o The DS RR has been authenticated using some KEY RR in the parent's
- apex KEY RRset (see Section 5.2);
-
- o The Algorithm and Key Tag in the DS RR match the Algorithm field
- and the key tag of a KEY RR in the child zone's apex KEY RRset
- which, when hashed using the digest algorithm specified in the DS
- RR's Digest Type field, results in a digest value which matches
- the Digest field of the DS RR; and
-
- o The matching KEY RR in the child zone has the Zone Flag bit set to
- one, the corresponding private key has signed the child zone's
- apex KEY RRset, and the resulting SIG RR authenticates the child
- zone's apex KEY RRset.
-
- If the referral from the parent zone did not contain a DS RRset, the
- response should have included a signed NXT RRset proving that no DS
- RRset exists for the delegated name (see Section 3.4). A security-
- aware resolver MUST send the parent a query for the DS RRset if the
- referral includes neither a DS RRset nor a NXT RRset proving the
- nonexistence of the DS RRset (see Section 4).
-
- If the resolver authenticates an NXT RRset which proves that no DS
- RRset is present for this zone, then there is no authentication path
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 26]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- leading from the parent to the child. If the resolver has an initial
- KEY RR which belongs to the child zone or to any delegation below the
- child zone, this initial KEY RR MAY be used to re-establish an
- authentication path. If no such initial KEY RR exists, the resolver
- can not authenticate RRsets at or below the child zone.
-
- Note that, for a signed delegation, there are two NXT RRs associated
- with the delegated name. One NXT RR resides in the parent zone, and
- can be used to prove whether a DS RRset exists for the delegated
- name. The second NXT RR resides in the child zone, and identifies
- which RRsets are present at the apex of the child zone. The parent
- NXT RR and child NXT RR can always be distinguished, since the SOA
- bit will be set in the child NXT RR and clear in the parent NXT RR.
- A security-aware resolver MUST use the parent NXT RR when attempting
- to prove that a DS RRset does not exist.
-
-5.2 Authenticating an RRSet Using a SIG RR
-
- A resolver can use a SIG RR and its corresponding KEY RR to attempt
- to authenticate RRsets. The resolver first checks the SIG RR to
- verify that it covers the RRset, has a valid time interval, and
- identifies a valid KEY RR. The resolver then constructs the
- canonical form of the signed data by appending the SIG RDATA
- (excluding the Signature Field) with the canonical form of the
- covered RRset. Finally, resolver uses the public key and signature
- to authenticate the signed data. Section 5.2.1, Section 5.2.2, and
- Section 5.2.3 describe each step in detail.
-
-5.2.1 Checking the SIG RR Validity
-
- A security-aware resolver can use a SIG RR to authenticate an RRset
- if all of the following conditions hold:
-
- o The SIG RR and the RRset MUST have the same owner name and the
- same class;
-
- o The SIG RR's Signer's Name field MUST be the name of the zone that
- contains the RRset;
-
- o The SIG RR's Type Covered field MUST equal the RRset's type;
-
- o The number of labels in the RRset owner name MUST be greater than
- or equal to the value in the SIG RR's Labels field;
-
- o The resolver's notion of the current time MUST be less than or
- equal to the time listed in the SIG RR's Expiration field;
-
- o The resolver's notion of the current time MUST be greater than or
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 27]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- equal to the time listed in the SIG RR's Inception field;
-
- o The SIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
- match the owner name, algorithm, and key tag for some KEY RR in
- the zone's apex KEY RRset;
-
- o The matching KEY RR MUST be present in the zone's apex KEY RRset,
- and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) set to one.
-
- It is possible for more than one KEY RR to match the conditions
- above. In this case, the resolver can not predetermine which KEY RR
- to use to authenticate the signature, MUST try each matching KEY RR
- until the resolver has either validated the signature or has run out
- of matching keys to try.
-
- Note that this authentication process is only meaningful if the
- resolver authenticates the KEY RR before using it to validate
- signatures. The matching KEY RR is considered to be authentic if:
-
- o The apex KEY RRset containing the KEY RR is considered authentic;
- or
-
- o The RRset covered by the SIG RR is the apex KEY RRset itself, and
- the KEY RR either matches an authenticated DS RR from the parent
- zone or matches a DS RR or KEY RR which the resolver has been
- preconfigured to believe to be authentic.
-
-
-5.2.2 Reconstructing the Signed Data
-
- Once the SIG RR has met the validity requirements described in
- Section 5.2.1, the resolver needs to reconstruct the original signed
- data. The original signed data includes SIG RDATA (excluding the
- Signature field) and the canonical form of the RRset. Aside from
- being ordered, the canonical form of the RRset might also differ from
- the received RRset due to DNS name compression, decremented TTLs, or
- wildcard expansion. The resolver should use the following to
- reconstruct the original signed data:
-
- signed_data = SIG_RDATA | RR(1) | RR(2)... where
-
- "|" denotes concatenation
-
- SIG_RDATA is the wire format of the SIG RDATA fields with
- the Signature field excluded and the Signer's Name in
- canonical form.
-
- RR(i) = name | class | type | OrigTTL | RDATA length | RDATA
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 28]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- name is calculated according to the function below
-
- class is the RRset's class
-
- type is the RRset type and all RRs in the class
-
- OrigTTL is the value from the SIG Original TTL field
-
- All names in the RDATA field are in canonical form
-
- The set of all RR(i) is sorted into canonical order.
-
- To calculate the name:
- let sig_labels = the value of the SIG Labels field
-
- let fqdn = RRset's fully qualified domain name in
- canonical form
-
- let fqdn_labels = RRset's fully qualified domain name in
- canonical form
-
- if sig_labels = fqdn_labels,
- name = fqdn
-
- if sig_labels < fqdn_labels,
- name = "*." | the leftmost sig_label labels of the
- fqdn
-
- if sig_labels > fqdn
- the SIG RR did not pass the necessary validation
- checks and MUST NOT be used to authenticate this
- RRset.
-
- Editors' note: The algorithm above needs to be cross-checked very
- carefully against the definitions in [10].
-
- Section 5.4.1 gives an example of original name calculation. The
- canonical forms for names and RRsets are defined in [10].
-
- NXT RRsets at a delegation boundary require special processing.
- There are two distinct NXT RRsets associated with a signed delegated
- name. One NXT RRset resides in the parent zone, and specifies which
- RRset are present at the parent zone. The second NXT RRset resides
- at the child zone, and identifies which RRsets are present at the
- apex in the child zone. The parent NXT RRset and child NXT RRset can
- always be distinguished since only the child NXT RRs will specify an
- SOA RRset exists at the name. When reconstructing the original NXT
- RRset for the delegation from the parent zone, the NXT RRs MUST NOT
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 29]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- be combined with NXT RRs from the child zone, and when reconstructing
- the original NXT RRset for the apex of the child zone, the NXT RRs
- MUST NOT be combined with NXT RRs from the parent zone.
-
- Note also that each of the two NXT RRsets at a delegation point has a
- corresponding SIG RR with an owner name matching the delegated name,
- and each of these SIG RRs is authoritative data associated with the
- same zone which contains the corresponding NXT RRset. If necessary,
- a resolver can tell these SIG RRs apart by checking the Signer's Name
- field.
-
-5.2.3 Checking the Signature
-
- Once the resolver has validated the SIG RR as described in Section
- 5.2.1 and reconstructed the original signed data as described in
- Section 5.2.2, the resolver can attempt to use the cryptographic
- signature to authenticate the signed data, and thus (finally!)
- authenticate the RRset.
-
- The Algorithm field in the SIG RR identifies the cryptographic
- algorithm to generate the signature. The signature itself is
- contained in the Signature field of the SIG RDATA, and the public key
- to used generate the signature is contained in the Public Key field
- of the matching KEY RR(s) (found in Section 5.2.1). [10] provides a
- list of algorithm types, and provides pointers to the documents that
- define each algorithm's use.
-
- Note that it is possible for more than one KEY RR to match the
- conditions in Section 5.2.1. In this case, the resolver can only
- determine which KEY RR by trying each matching key until the resolver
- either succeeds in validating the signature or runs out of keys to
- try.
-
- If the Labels field of the SIG RR is not equal to the number of
- labels in the RRset's fully qualified owner name, then the RRset is
- either invalid or the result of wildcard expansion. The resolver
- MUST verify that wildcard expansion was applied properly before
- considering the RRset to be authentic. Section 5.2.4 describes how
- to determine whether a wildcard was applied properly.
-
- If other SIG RRs also cover this SIG RR, the local resolver security
- policy determines whether the resolver also needs to test these SIG
- RRs, and determines how to resolve conflicts if these SIG RRs lead to
- differing results.
-
- If the resolver accepts the RRset as authentic, the resolver MUST set
- the SIG RR's TTL and the TTL of each RR in the authenticated RRset to
- the minimum of:
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 30]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- o The RRset's TTL as received in the response;
-
- o The SIG RR's TTL as received in the response; and
-
- o The value in the SIG RR's Original TTL field.
-
-
-5.2.4 Authenticating A Wildcard Expanded RRset Positive Response
-
- If the number of labels in an RRset's fully qualified domain name is
- greater than the Labels field in the covering SIG RDATA, then the
- RRset and its covering SIG RR were created as a result of wildcard
- expansion. Once the resolver has verified the signature as described
- in Section 5.2, the resolver must take additional steps to verify the
- non-existence of an exact match or closer wildcard match for the
- query. Section 5.3 discusses these steps.
-
- Note that the response received by the resolver should include all
- NXT RRs needed to authenticate the response (see Section 3.3).
-
-5.3 Authenticated Denial of Existence
-
- A resolver can use authenticated NXT RRs to prove that an RRset is
- not present in a signed zone. Security-aware name servers should
- automatically include any necessary NXT RRs for signed zones in their
- responses to security-aware resolvers.
-
- Security-aware resolvers MUST first authenticate NXT RRsets according
- to the standard RRset authentication rules described in Section 5.2,
- then apply the NXT RRsets as follows:
-
- o If the requested RR name matches the owner name of an
- authenticated NXT RR, then the NXT RR's type bit map field lists
- all RR types present at that owner name, and a resolver can prove
- that the requested RR type does not exist by checking for the RR
- type in the bit map. Since the existence of the authenticated NXT
- RR proves that the owner name exists in the zone, wildcard
- expansion could not have been used to match the requested RR owner
- name and type.
-
- o If the requested RR name would appear after an authenticated NXT
- RR owner name and before the name listed in that NXT RR's Next
- Domain Name field according to the canonical DNS name order
- defined in [10], then no exact match for the requested RR name
- exists in the zone. However, it is possible that a wildcard could
- be used to match the requested RR owner name and type, so proving
- that the requested RRset does not exist also requires proving that
- no possible wildcard exists which could have been used to generate
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 31]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- a positive response.
-
- To prove non-existence of an RRset, the resolver must be able to
- verify both that the queried RRset does not exist and that no
- relevant wildcard RRset exists. Proving this may require more than
- one NXT RRset from the zone. If the complete set of necessary NXT
- RRsets is not present in a response (perhaps due to truncation), then
- a security-aware resolver MUST resend the query in order to attempt
- to obtain the full collection of NXT RRs necessary to verify non-
- existence of the requested RRset. As with all DNS operations,
- however, the resolver MUST bound the work it puts into answering any
- particular query.
-
-5.4 Example
-
-5.4.1 Example of Re-Constructing the Original Owner Name
-
- Suppose that a security-aware resolver receives a response containing
- an answer RRset with an owner name of is "www.a.b.c.example.com".
- This fully qualified domain name has 6 labels: "www", "a", "b", "c",
- "example", and "com". What name the resolver should use when
- reconstructing the original signed data depends on the value of the
- SIG RR's Labels field.
-
- If the value of the SIG RR's Labels field is 6, then the SIG RR's
- Labels field matches the number of labels in the owner name, and the
- resolver should assume that this RRset is not the result of wildcard
- expansion. The resolver should therefore use "www.a.b.c.example.com"
- as the owner name when reconstructing the original signed data for
- the signature check.
-
- If the value of the SIG RR's Labels field is less than 6, then the
- SIG RR's Labels count is less than the number of labels in the
- RRset's owner name, and the resolver should assume that this RRset is
- the result of wildcard expansion. The resolver should therefore
- reconstruct the original owner name by replacing the labels which
- appear to be the result of wildcard expansion with a single "*."
- label. For example, if the SIG RR's Labels field is 3, the resolver
- should reconstruct the original owner name by prepending "*." to the
- last 3 labels of the owner name of the answer RRset. Thus, the
- resolver should use "*.c.example.com" as the owner name when
- reconstructing the original signed data.
-
- If the value of the SIG RR's Labels field is greater than 6, then
- this SIG RR cannot possibly be valid for the answer RRset, and there
- is no point in attempting to validate the signature.
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 32]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-5.4.2 Examples of Authenticating a Response
-
- Editors' note: Eventually this will be an example of the
- authentication process for "www.example.com", starting from an
- initial root key.
-
- Editors' note: Eventually this will be an example of the
- authentication process for non-existent "www.a.b.c.example.com",
- starting from an initial root key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 33]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-6. IANA Considerations
-
- This document introduces no IANA considerations.
-
- [10] contains a complete review of the IANA considerations introduced
- by DNSSEC.
-
- Editors' note: This may not be true anymore, since the AD and CD
- bit definitions are now in this document rather than in [10].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 34]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-7. Security Considerations
-
- This document describes how the DNS security extensions use public
- key cryptography to sign and authenticate DNS resource record sets.
-
- At this time, at least two substantial elements of the DNSSEC
- specification have yet to be decided by the working group. The open
- opt-in issue would change elements such as what RRsets must be
- signed, would impact how wildcards are used, and would replace
- authenticated denial of existence with authenticated denial of
- security. Handling of the AD bit is also undecided. The AD bit (as
- currently defined) is used to indicate the security status of RRsets
- in the response. These items clearly raise security considerations
- and will be addressed here as these issues are resolved in the
- working group.
-
- DNSSEC introduces a number of denial of service issues. These issues
- will also be addressed in a future version of these security
- considerations.
-
- Please see [9] for general security considerations related to DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 35]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-8. Acknowledgements
-
- This document was created from the input and ideas of several members
- of the DNS Extensions Working Group and working group mailing list.
- The co-authors of this draft would like to express their thanks for
- the comments and suggestions received during the revision of these
- security extension specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 36]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
- August 1996.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
- [7] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [8] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
- [9] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirements", draft-ietf-
- dnsext-dnssec-intro-05 (work in progress), February 2003.
-
- [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "Resource Records for DNS Security Extensions", draft-ietf-
- dnsext-dnssec-records-04 (work in progress), February 2003.
-
- [11] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft-
- ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 37]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-Informative References
-
- [12] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
- 2930, September 2000.
-
- [14] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [15] Gudmundsson, O., "Delegation Signer Resource Record", draft-
- ietf-dnsext-delegation-signer-12 (work in progress), December
- 2002.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Rob Austein
- Internet Software Consortium
- 40 Gavin Circle
- Reading, MA 01867
- USA
-
- EMail: sra@isc.org
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 38]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.edu
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 39]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-Appendix A. Algorithm For Handling Wildcard Expansion
-
- For zone (Z) and a name (N) that may occur in Z, the following
- algorithm finds all wildcard RRsets that match N or returns an NXT
- RRset that proves no wildcard expansion matches N. The algorithm was
- written for clarity, not efficiency:
-
- 0. INPUT: a name (N) and a zone (Z).
- INIT: NXT_SET = NULL
-
- 1. Construct S = sequence of all names in Z, sorted
- into canonical order.
-
- 2. If N exists in S
- There is an exact match for N.
- Return all RRsets associated with N
- Else
- Add the name that would immediately
- precede N in S to NXT_SET.
- EndIf
-
- 3. Replace the leftmost label of N with *
-
- 4. If N exists in S
- There is a positive wildcard match for N.
- Return all RRsets associated with N
- Else
- Add the NXT for name that would immediately
- precede N in S to NXT_SET.
- EndIf
-
- 5. Remove the leading * from N.
-
- 6. If N exists in S
- There is a name that terminates the wildcard search.
- Add the NXT for N to NXT_SET and return NXT_SET.
- Else
- Goto Step 3
- EndIf
-
- Note: the algorithm is guaranteed to terminate since
- eventually there will be a match or N will be
- reduced to zone name itself and the zone name
- must exist in S.
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 40]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). 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 September 1, 2003 [Page 41]
-\f
--- /dev/null
+
+
+DNS Extensions R. Arends
+Internet-Draft Telematica Instituut
+Expires: March 30, 2004 M. Larson
+ VeriSign
+ R. Austein
+ ISC
+ D. Massey
+ USC/ISI
+ S. Rose
+ NIST
+ September 30, 2003
+
+
+ Protocol Modifications for the DNS Security Extensions
+ draft-ietf-dnsext-dnssec-protocol-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 March 30, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ This document is part of a family of documents which describes the
+ DNS Security Extensions (DNSSEC). The DNS Security Extensions are a
+ collection of new resource records and protocol modifications which
+ add data origin authentication and data integrity to the DNS. This
+ document describes the DNSSEC protocol modifications. This document
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 1]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ defines the concept of a signed zone, along with the requirements for
+ serving and resolving using DNSSEC. These techniques allow a
+ security-aware resolver to authenticate both DNS resource records and
+ authoritative DNS error indications.
+
+ This document obsoletes RFC 2535 and incorporates changes from all
+ updates to RFC 2535.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Background and Related Documents . . . . . . . . . . . . . . 4
+ 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
+ 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
+ 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
+ 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6
+ 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6
+ 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7
+ 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
+ 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
+ 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8
+ 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 9
+ 3.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10
+ 3.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 10
+ 3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not
+ Present . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches . . . 11
+ 3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches . . . . . 11
+ 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 12
+ 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 12
+ 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 13
+ 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 14
+ 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 15
+ 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 21
+ 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 22
+ 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 24
+ 5.1 Special Considerations for Islands of Security . . . . . . . 25
+ 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 25
+ 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 26
+ 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 27
+ 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28
+ 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 29
+ 5.3.4 Authenticating A Wildcard Expanded RRset Positive
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 2]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ Response . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 30
+ 5.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 5.5.1 Example of Re-Constructing the Original Owner Name . . . . . 31
+ 5.5.2 Examples of Authenticating a Response . . . . . . . . . . . 32
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . 34
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
+ Normative References . . . . . . . . . . . . . . . . . . . . 36
+ Informative References . . . . . . . . . . . . . . . . . . . 37
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
+ A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 39
+ B. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40
+ Intellectual Property and Copyright Statements . . . . . . . 46
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 3]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+1. Introduction
+
+ The DNS Security Extensions (DNSSEC) are a collection of new resource
+ records and protocol modifications which add data origin
+ authentication and data integrity to the DNS. This document defines
+ the DNSSEC protocol modifications. Section 2 of this document defines
+ the concept of a signed zone and lists the requirements for zone
+ signing. Section 3 describes the modifications to authoritative name
+ server behavior necessary to handle signed zones. Section 4 describes
+ the behavior of entities which include security-aware resolver
+ functions. Finally, Section 5 defines how to use DNSSEC RRs to
+ authenticate a response.
+
+1.1 Background and Related Documents
+
+ The reader is assumed to be familiar with the basic DNS concepts
+ described in RFC1034 [RFC1034] and RFC1035 [RFC1035].
+
+ This document is part of a family of documents which define DNSSEC.
+ An introduction to DNSSEC and definition of common terms can be found
+ in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC
+ resource records can be found in [I-D.ietf-dnsext-dnssec-records].
+
+1.2 Reserved Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119. [RFC2119].
+
+1.3 Editors' Notes
+
+1.3.1 Open Technical Issues
+
+1.3.2 Technical Changes or Corrections
+
+ Please report technical corrections to dnssec-editors@east.isi.edu.
+ To assist the editors, please indicate the text in error and point
+ out the RFC that defines the correct behavior. For a technical
+ change where no RFC that defines the correct behavior, or if there's
+ more than one applicable RFC and the definitions conflict, please
+ post the issue to namedroppers.
+
+ An example correction to dnssec-editors might be: Page X says
+ "DNSSEC RRs SHOULD be automatically returned in responses." This was
+ true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
+ DNSSEC RR types MUST NOT be included in responses unless the resolver
+ indicated support for DNSSEC.
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 4]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+1.3.3 Typos and Minor Corrections
+
+ Please report any typos corrections to dnssec-editors@east.isi.edu.
+ To assist the editors, please provide enough context for us to find
+ the incorrect text quickly.
+
+ An example message to dnssec-editors might be: page X says "the
+ DNSSEC standard has been in development for over 1 years". It
+ should read "over 10 years".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 5]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+2. Zone Signing
+
+ DNSSEC is built around the concept of signed zones. A signed zone
+ includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
+ the rules specified in Section 2.1, Section 2.2, Section 2.3 and
+ Section 2.4, respectively. Any zone which does not include these
+ records according to the rules in this section MUST be considered
+ unsigned for the purposes of the DNS security extensions.
+
+ DNSSEC requires a change to the definition of the CNAME resource
+ record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs
+ to appear at the same owner name as a CNAME RR.
+
+ Section 2.6 shows a sample signed zone.
+
+2.1 Including DNSKEY RRs in a Zone
+
+ To sign a zone, the zone's administrator generates one or more
+ public/private key pairs and uses the private key(s) to sign
+ authoritative RRsets in the zone. For each private key used to
+ create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR
+ stored in the zone. A zone key DNSKEY RR has the Zone Key bit of the
+ flags RDATA field set to one -- see Section 2.1.1 of
+ [I-D.ietf-dnsext-dnssec-records]. Public keys associated with other
+ DNS operations MAY be stored in DNSKEY RRs that are not marked as
+ zone keys.
+
+ If the zone is delegated and does not wish to act as an island of
+ security, the zone MUST have at least one DNSKEY RR at the apex to
+ act as a secure entry point into the zone. This DNSKEY would then be
+ used to generate a DS RR at the delegating parent (see
+ [I-D.ietf-dnsext-dnssec-records]). This DNSKEY RR SHOULD be either a
+ zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro]
+ for definition). The DNSKEY RRset at the zone apex MUST be signed by
+ at least one zone signing or DNSKEY signing private key.
+
+ DNSKEY RRs MUST NOT appear at delegation points.
+
+2.2 Including RRSIG RRs in a Zone
+
+ For each authoritative RRset in a signed zone (which excludes both NS
+ RRsets at delegation points and glue RRsets), there MUST be at least
+ one RRSIG record that meets all of the following requirements:
+
+ o The RRSIG owner name is equal to the RRset owner name;
+
+ o The RRSIG class is equal to the RRset class;
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 6]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ o The RRSIG Type Covered field is equal to the RRset type;
+
+ o The RRSIG Original TTL field is equal to the TTL of the RRset;
+
+ o The RRSIG RR's TTL is equal to the TTL of the RRset;
+
+ o The RRSIG Labels field is equal to the number of labels in the
+ RRset owner name, not counting the null root label and not
+ counting the wildcard label if the owner name is a wildcard;
+
+ o The RRSIG Signer's Name field is equal to the name of the zone
+ containing the RRset; and
+
+ o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
+ zone key DNSKEY record at the zone apex.
+
+ The process for constructing the RRSIG RR for a given RRset is
+ described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
+ multiple RRSIG RRs associated with it.
+
+ An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
+ would add no value and would create an infinite loop in the signing
+ process.
+
+ The NS RRset which appears at the zone apex name MUST be signed, but
+ the NS RRsets which appear at delegation points (that is, the NS
+ RRsets in the parent zone which delegate the name to the child zone's
+ name servers) MUST NOT be signed. Glue address RRsets associated with
+ delegations MUST NOT be signed.
+
+ The difference between the set of owner names which require RRSIG
+ records and the set of owner names which require NSEC records is
+ subtle and worth highlighting. RRSIG records are present at the
+ owner names of all authoritative RRsets. NSEC records are present at
+ the owner names of all names for which the signed zone is
+ authoritative and also at the owner names of delegations from the
+ signed zone to its children. Neither NSEC nor RRSIG records are
+ present (in the parent zone) at the owner names of glue address
+ RRsets. Note, however, that this distinction is for the most part
+ only visible during the zone signing process, because NSEC RRsets are
+ authoritative data, and are therefore signed, thus any owner name
+ which has an NSEC RRset will have RRSIG RRs as well in the signed
+ zone.
+
+2.3 Including NSEC RRs in a Zone
+
+ Each owner name in the zone MUST have an NSEC resource record, except
+ for the owner names of any glue address RRsets. The process for
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 7]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ constructing the NSEC RR for a given name is described in
+ [I-D.ietf-dnsext-dnssec-records].
+
+ The type bitmap of every NSEC resource record in a signed zone MUST
+ indicate the presence of both the NSEC record itself and its
+ corresponding RRSIG record.
+
+2.4 Including DS RRs in a Zone
+
+ The DS resource record establishes authentication chains between DNS
+ zones. A DS RRset SHOULD be present at a delegation point when the
+ child zone is signed. The DS RRset MAY contain multiple records,
+ each referencing a key used by the child zone to sign its apex DNSKEY
+ RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT
+ appear at non-delegation points nor at a zone's apex.
+
+ A DS RR SHOULD point to a DNSKEY RR which is present in the child's
+ apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
+ by the corresponding private key.
+
+ Construction of a DS RR requires knowledge of the corresponding
+ DNSKEY RR in the child zone, which implies communication between the
+ child and parent zones. This communication is an operational matter
+ not covered by this document.
+
+2.5 Changes to the CNAME Resource Record.
+
+ If a CNAME RRset is present at a name in a signed zone, appropriate
+ RRSIG and NSEC RRsets are REQUIRED at that name. Other types MUST NOT
+ be present at that name.
+
+ This is a modification to the original CNAME definition given in
+ [RFC1034]. The original definition of the CNAME RR did not allow any
+ other types to co-exist with a CNAME record, but a signed zone
+ requires NSEC and RRSIG RRs for every authoritative name. To resolve
+ this conflict, this specification modifies the definition of the
+ CNAME resource record to allow it to co-exist with NSEC and RRSIG
+ RRs.
+
+2.6 Example of a Secure Zone
+
+ Appendix B shows a complete example of a small signed zone.
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 8]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+3. Serving
+
+ This section describes the behavior of a security-aware authoritative
+ name server. A security-aware authoritative name server MUST support
+ the EDNS0 [RFC2671] message size extension, MUST support a message
+ size of at least 1220 octets, and SHOULD support a message size of
+ 4000 octets [RFC3226]. Since functions specific to security-aware
+ recursive name servers included components of both resolving and
+ serving, issues specific to security-aware recursive name servers are
+ described in Section 4.
+
+ Upon receiving a relevant query which has the EDNS [RFC2671] OPT
+ pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
+ name server for a signed zone MUST include additional RRSIG, NSEC,
+ and DS RRs according to the following rules:
+
+ o RRSIG RRs which can be used to authenticate a response MUST be
+ included in the response according to the rules in Section 3.1;
+
+ o NSEC RRs which can be used to provide authenticated denial of
+ existence MUST be included in the response automatically according
+ to the rules in Section 3.3;
+
+ o Either DS RRs or an NSEC RR proving that no DS RRs exist MUST be
+ included in referrals automatically according to the rules in
+ Section 3.4.
+
+ DNSSEC does not change the DNS zone transfer protocol. Zone transfer
+ requirements are reviewed in Section 3.6.
+
+ A security-aware name server which receives a DNS query which does
+ not include the EDNS OPT pseudo-RR or which has the DO bit set to
+ zero MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
+ RRset, and MUST NOT perform any of the additional processing
+ described above. Since the DS RR type has the peculiar property of
+ only existing in the parent zone at delegation points, DS RRs always
+ require some special processing, as described in Section 3.5.
+
+3.1 Including RRSIG RRs in a Response
+
+ When a query has the DO bit set to one, the authoritative name server
+ SHOULD attempt to send RRSIG RRs which can be used to authenticate
+ the RRsets in the response. Inclusion of RRSIG RRs in a response is
+ subject to the following rules:
+
+ o When placing a signed RRset in the Answer section, the name server
+ MUST also place its RRSIG RRs in the Answer section. The RRSIG
+ RRs have a higher priority for inclusion than any other RRsets
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 9]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ which may need to be included. If space does not permit inclusion
+ of these RRSIG RRs, the name server MUST set the TC bit.
+
+ o When placing a signed RRset in the Authority section, the name
+ server MUST also place its RRSIG RRs in the Authority section.
+ The RRSIG RRs have a higher priority for inclusion than any other
+ RRsets that may need to be included. If space does not permit
+ inclusion of these RRSIG RRs, the name server MUST set the TC bit.
+
+ o When placing a signed RRset in the Additional section, the name
+ server MUST also place its RRSIG RRs in the Additional section.
+ If space does not permit inclusion of these RRSIG RRs, the name
+ server MUST NOT set the TC bit solely because these RRSIG RRs
+ didn't fit.
+
+
+3.2 Including DNSKEY RRs In a Response
+
+ When a query has the DO bit set to one and requests the SOA or NS RRs
+ at the apex of a signed zone, a security-aware authoritative name
+ server for that zone MAY return the DNSKEY RRset with the same name
+ in the Additional section. In this situation, the DNSKEY RR set and
+ associated RRSIG RRs have lower priority than any other information
+ that would be placed in the additional section. The name server
+ should include the DNSKEY RRset if and only if there is enough space
+ in the response for both the DNSKEY RRset and associated RRSIG RR(s).
+ If there is not enough space to include these DNSKEY and RRSIG RRs,
+ the name server MUST omit them and MUST NOT set the TC bit solely
+ because these RRs didn't fit.
+
+3.3 Including NSEC RRs In a Response
+
+ When a query has the DO bit set to one, security-aware authoritative
+ name servers for a signed zone MUST include NSEC RRs in each of the
+ following cases:
+
+ Case 1: The QNAME has RRsets associated with it in the zone, but the
+ requested RR type does not exist.
+
+ Case 2: The QNAME, QTYPE, QCLASS tuple does not exist, and no
+ wildcard can be expanded to answer the query.
+
+ Case 3: The QNAME (or search name) does not exist, but a wildcard can
+ be expanded to positively answer the query.
+
+ Note that, in each case, a set of NSEC RRs is included to provide
+ authenticated denial of existence.
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 10]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not Present
+
+ If there are RR types associated with a given QNAME, but the
+ requested RR type is not present at the name, then the name server
+ MUST include the NSEC RR associated with the query name and any RRSIG
+ RRs associated with the NSEC RR in the Authority section (see Section
+ 3.1). If space does not permit inclusion of the NSEC RR or its
+ associated RRSIG RRs, the name server MUST set the TC bit.
+
+ Note that, since the query name exists, no wildcard expansion applies
+ to this query, and a single NSEC RR suffices to prove the requested
+ RR type does not exist.
+
+3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches
+
+ If the query name does not exist in the zone, and no wildcard
+ expansion matches both the query name and the query type, the name
+ server MUST include the following NSEC RRs in the Authority section,
+ along with their associated RRSIG RRs:
+
+ o An NSEC RR proving that there was no exact match for the name; and
+
+ o An NSEC RR combination proving that there was no wildcard which
+ would have matched the query. See [I-D.ietf-dnsext-wcard-clarify]
+ for further information on NSEC coverage.
+
+ If space does not permit inclusion of these NSEC and RRSIG RRs, the
+ name server MUST set the TC bit (see Section 3.1).
+
+ Appendix A provides an algorithm which computes the appropriate NSEC
+ RRs to prove that no wildcard matches a given query name.
+
+3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches
+
+ If the query name does not exist, but a wildcard expansion can be
+ used to return a positive match to the query, the name server MUST
+ include the wildcard-expanded answer and the corresponding
+ wildcard-expanded RRSIG RRs in the Answer section. The Authority
+ section of the response MUST include the following NSEC RRs along
+ with their corresponding RRSIG RRs:
+
+ o An NSEC RR which proves that there were no exact matches for the
+ QNAME and QTYPE; and
+
+ o An NSEC RR combination which proves that there are no closer
+ wildcard entries which could have been expanded to match the
+ query. See [I-D.ietf-dnsext-wcard-clarify] for further
+ information on NSEC coverage.
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 11]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ If space does not permit inclusion of these NSEC and RRSIG RRs, the
+ name server MUST set the TC bit (see Section 3.1).
+
+ Appendix A provides an algorithm which computes the appropriate NSEC
+ RRs to prove that no closer wildcard matches the query name.
+
+3.4 Including DS RRs In a Response
+
+ When a query has the DO bit set to one, and a DS RR exists at the
+ query name, an authoritative security-aware name server returning a
+ referral for the delegation MUST include both the NS RRset and also
+ the DS RRset and its associated RRSIG RR(s). The name server MUST
+ place the NS RRset before the DS RRset and its associated RRSIG RRs.
+
+ When a query has the DO bit set to one, and no DS RR exists at the
+ query name, an authoritative security-aware name server returning a
+ referral for the delegation MUST include both the NS RRset and also
+ the NSEC RR and associated RRSIG RR(s) which proves that the DS RRset
+ does not exist. The name server MUST place the NS RRset before the
+ NSEC RRset and its associated RRSIG RR(s).
+
+ Including these DS and RRSIG RRs increases the size of referral
+ messages, and may cause some or all glue RRs to be omitted. If space
+ does not permit inclusion of the DS or NSEC RRset and associated
+ RRSIG RRs, the name server MUST set the TC bit.
+
+ Security-aware name servers also include NSEC RRs in a referral
+ response when no DS RR is present; in this case, the NSEC RR proves
+ that no DS RR exists for the delegation. Section 3.4 discusses
+ referrals in more detail.
+
+3.5 Responding to Queries for DS RRs
+
+ The DS resource record type is unusual in that it appears only on the
+ parent zone's side of a zone cut. In other words, the DS record for
+ the delegation of "example.com" is only stored in the "com" zone.
+ This introduces novel name server behavior, since the name server for
+ the child zone is authoritative for the name by the normal DNS rules
+ but the child zone does not contain the DS RR. An authoritative name
+ server's response to a DS query depends on whether the name server is
+ authoritative for the parent zone, the child zone, or both, as
+ described below.
+
+ If a name server is authoritative for the parent zone, and receives a
+ query for the DS record at the delegated name, then the name server
+ MUST return the DS RRset from the parent zone. This rule applies
+ regardless of whether or not the name server is also authoritative
+ for the child zone.
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 12]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ If the name server is authoritative for the child zone, is not
+ authoritative for the parent zone, and receives a query for the DS
+ record at the delegated name, there is no obvious response, because
+ the child zone is not authoritative for the DS record at the child
+ zone's apex, and the authoritative DS RR is only stored at the
+ parent.
+
+ If the name server allows recursion, and the RD bit is set in the
+ query, the name server MAY perform recursion to find the DS record
+ for the delegated name from the parent zone, and MAY return the DS
+ record from its cache. In this case, the AA bit MUST NOT be set in
+ the response.
+
+ If the name server does not perform recursion to find the DS RR, the
+ name server MUST reply with:
+
+ RCODE: NOERROR
+ AA bit: set
+ Answer Section: Empty
+ Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)]
+
+ In other words, a name server which is authoritative for the child
+ zone but not for the parent zone answers as if the DS record does not
+ exist. Note that security-aware resolvers will query the parent zone
+ at delegation points, and thus will not be affected by this behavior.
+
+ For example, suppose that "example.com" is a delegation point, and a
+ name server receives a query for the "example.com" DS RRset.
+
+ o If the name server is authoritative for "com", the name server
+ MUST reply with the "example.com" DS RRset from the "com" zone.
+
+ o If the name server is authoritative for "example.com", is not
+ authoritative for "com", and the RD bit is set to one in the
+ query, the name server MAY perform recursion to find the
+ "example.com" DS record. If the name server does not use
+ recursion to obtain the DS RR, the name server MUST reply as
+ though the DS RR did not exist:
+
+ RCODE: NOERROR
+ AA bit: set
+ Answer Section: Empty
+ Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)]
+
+
+3.6 Responding to Queries for Type AXFR or IXFR
+
+ DNSSEC does not change the DNS zone transfer process. A signed zone
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 13]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
+ records have no special meaning with respect to a zone transfer
+ operation, and these RRs are treated as any other resource record
+ type.
+
+ An authoritative name server is not required to verify that a zone is
+ properly signed before sending or accepting a zone transfer.
+ However, an authoritative name server MAY choose to reject the entire
+ zone transfer if the zone fails meets any of the signing requirements
+ described in Section 2. The primary objective of a zone transfer is
+ to ensure that all authoritative name servers have identical copies
+ of the zone. An authoritative name server which chooses to perform
+ its own zone validation MUST NOT selectively reject some RRs and
+ accept others.
+
+ Note that the DS RR appears only in the parental side of a delegation
+ and is authoritative data in the parent zone. For example, the DS RR
+ for "example.com" is stored in the "com" zone (the parent zone)
+ rather than in the "example.com" zone (the child zone). As with any
+ other authoritative RRset, the "example.com" DS RR MUST be included
+ the "com" zone transfer.
+
+ Note that authoritative NSEC RRs appear in both the parent and child
+ zones at a delegated name, and that the NSEC RRs for the delegated
+ name in the parent and child zones are never identical to each other.
+ As with any other authoritative RRset, the parental NSEC RR at a
+ delegated name MUST be included zone transfers of the parent zone,
+ while the NSEC at the zone apex of the child zone MUST be included in
+ zone transfers of the child zone.
+
+3.7 Setting the AD and CD Bits in a Response
+
+ Editors' note: This section seems a little lost here. Perhaps we
+ should rearrange the section ordering slightly, or provide a
+ pointer to this subsection at the beginning of Section 3.
+
+ DNSSEC allocates two new bits in the DNS message header: The CD
+ (Checking Disabled) bit and the AD (Authentic Data) bit.
+
+ The CD bit is set in query messages by the resolver, and MUST be
+ copied into the response by the name server. If the CD bit is set to
+ one, it indicates that the resolver is willing to perform whatever
+ authentication its local policy requires, and thus that the name
+ server need not perform authentication on the RRsets in the response.
+
+ Regardless of the setting of the CD bit, the name server MAY choose
+ whether or not to perform authentication according to its own local
+ name server policy, and the name server MAY use the CD bit as input
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 14]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ to its own local policy. However, if the resolver has set the CD
+ bit, a name server SHOULD, if possible, return the requested data to
+ the resolver even if the name server's local authentication policy
+ would reject the records in question. That is, by setting the CD
+ bit, the resolver has taken responsibility for performing its own
+ authentication, and the name server should not interfere in this
+ case.
+
+ The AD bit is set by name servers, and indicates the data in the
+ response has been authenticated by the name server, according to the
+ local name server policy. The AD bit MUST NOT be set on a response
+ unless all of the RRsets in the Answer and Authority sections have
+ met the name server's local authentication policy. A resolver MUST
+ NOT trust the AD bit unless it communicates with the name server over
+ a secure transport mechanism and is explicitly configured to trust
+ the name server's policy.
+
+3.8 Example DNSSEC Responses
+
+ Editors' note: these examples probably ought to move to an
+ appendix and probably ought to use the "real" signed example zone
+ that's already in an appendix.
+
+ The examples in this section use the following example zone to
+ demonstrate the formation of replies by an authoritative name server.
+ The zone has two name servers, a single child, and a wildcard MX RR.
+ The zone is completely signed and has a full NSEC chain.
+
+ example.com. SOA (...)
+ RRSIG SOA ...
+ NS a.example.com.
+ NS b.example.com.
+ RRSIG NS ...
+ MX 10 a.example.com
+ RRSIG MX ...
+ DNSKEY ...
+ RRSIG DNSKEY ...
+ NSEC *.example.com.
+ * MX 10 a.example.com.
+ RRSIG MX ...
+ NSEC a.example.com.
+ a A 10.10.10.1
+ RRSIG A ...
+ NSEC b.example.com.
+ b A 10.10.10.2
+ RRSIG A ...
+ NSEC c.example.com.
+ c CNAME a.example.com.
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 15]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ RRSIG CNAME
+ NSEC sub.example.com.
+ sub NS ns.sub.example.com.
+ RRSIG NS
+ DS ...
+ RRSIG DS
+ NSEC *.example.com.
+ ns.sub A 10.10.10.3
+ sub-nosig NS ns.sub-nosig.example.com.
+ NSEC example.com.
+ ns.sub-nosig A 10.10.10.4
+
+ A query to the authoritative name server for this zone for
+ QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce:
+
+ Flags: QR=1, AA=1, RCODE=0 (NOERROR)
+ EDNS: DO=1, size=4000
+ QUERY:
+ c.example.com. IN A
+ ANSWER:
+ c.example.com. IN A a.example.com
+ IN RRSIG CNAME
+ a.example.com. IN A 10.10.10.1
+ IN RRSIG A
+ AUTHORITY:
+ example.com. IN NS a.example.com.
+ IN NS b.example.com.
+ IN RRSIG NS ...
+ ADDITIONAL:
+ a.example.com. IN A 10.10.10.1
+ IN RRSIG A ...
+ b.example.com. IN A 10.10.10.2
+ IN RRSIG A ...
+
+ A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would
+ results in a referral to a signed zone. The resolver can determine
+ that "sub.example.com" is signed because of the presence of the DS RR
+ with the hash of the "sub.example.com" zone key.
+
+ Flags: QR=1, AA=1, RCODE=0 (NOERROR)
+ EDNS: DO=1, size=4000
+ QUERY:
+ www.sub.example.com. IN A
+ ANSWER:
+ ;; empty
+ AUTHORITY:
+ sub.example.com. IN NS ns.sub.example.com.
+ IN DS ...
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 16]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ IN RRSIG DS ...
+ ADDITIONAL:
+ ns.sub.example.com. IN A 10.10.10.3
+
+ A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A
+ would result in a referral to an unsigned zone. The resolver knows
+ not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS
+ bit in the NSEC RR bitmap in the referral is not set. Even if DNSSEC
+ RRs are present in responses from "sub-nosig.example.com" name
+ servers, the resolver will not be able to construct a authentication
+ chain, since there is a break between "sub-nosig.example.com" and its
+ delegating parent zone.
+
+ Flags: QR=1, AA=1, RCODE=0 (NOERROR)
+ EDNS: DO=1, size=4000
+ QUERY:
+ www.sub-nosig.example.com. IN A
+ ANSWER:
+ ;; empty
+ AUTHORITY:
+ sub-nosig.example.com. IN NS ns.sub-nosig.example.com.
+ IN NSEC ;; (DS bit not set)
+ IN RRSIG NSEC ...
+ ADDITIONAL:
+ ns.sub-nosig.example.com. IN A 10.10.10.4
+
+ A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name
+ error, because the name does not exist and is not covered by wildcard
+ expansion. Therefore, the name server must present proof that the
+ name does not exist, and that no wildcard expansion is present which
+ could have been used to answer the query.
+
+ Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN)
+ EDNS: DO=1, size=4000
+ QUERY:
+ f.example.com. IN A
+ ANSWER:
+ ;; empty
+ AUTHORITY:
+ example.com. IN SOA ...
+ IN RRSIG SOA ...
+ c.example.com. IN NSEC sub.example.com. ...
+ IN RRSIG NSEC ...
+ *.example.com. IN NSEC a.example.com. ...
+ IN RRSIG NSEC ...
+ ADDITIONAL:
+ example.com. IN DNSKEY ...
+ IN RRSIG DNSKEY ...
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 17]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX
+ RR synthesized via wildcard expansion. The name server must prove
+ that no exact match exists.
+
+ Flags: QR=1, AA=1, RCODE=0 (NOERROR)
+ EDNS: DO=1, size=4000
+ QUERY:
+ f.example.com. IN MX
+ ANSWER:
+ f.example.com. IN MX 10 a.example.com.
+ IN RRSIG MX ...
+ AUTHORITY:
+ example.com. IN NS a.example.com.
+ IN NS b.example.com.
+ IN RRSIG NS ...
+ c.example.com. IN NSEC sub.example.com.
+ IN RRSIG NSEC ...
+ ADDITIONAL:
+ a.example.com. IN A 10.10.10.1
+ IN RRSIG A ...
+ b.example.com. IN A 10.10.10.2
+ IN RRSIG A ...
+
+ If these responses came from a recursive name server which had all of
+ the necessary RRsets in its cache instead of from an authoritative
+ server, the only differences would be the TTLs and the header flags.
+ The AA bit would not be set, and the AD bit would be set if (and only
+ if) all the RRsets in a response passed the security policy checks of
+ the recursive name server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 18]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+4. Resolving
+
+ This section describes the behavior of entities which include
+ security-aware resolver functions. In many cases such functions will
+ be part of a security-aware recursive name server, but a stand-alone
+ security-aware resolver has many of the same requirements. Functions
+ specific to security-aware recursive name servers are described in a
+ separate subsection.
+
+ A security-aware resolver MUST include an EDNS [RFC2671] OPT
+ pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
+
+ A security-aware resolver MUST support a message size of at least
+ 1220 octets, SHOULD support a message size of 4000 octets, and MUST
+ advertise the supported message size using the "sender's UDP payload
+ size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST
+ handle fragmented UDP packets correctly regardless of whether any
+ such fragmented packets were received via IPv4 or IPv6. Please see
+ [RFC3226] for discussion of these requirements.
+
+ A security-aware resolver MUST support the signature verification
+ mechanisms described in Section 5, and MUST apply them to every
+ received response except when:
+
+ o The security-aware resolver is part of a security-aware recursive
+ name server, and the response is the result of recursion on behalf
+ of a query received with the CD bit set;
+
+ o The response is the result of a query generated directly via some
+ form of application interface which instructed the security-aware
+ resolver not to perform validation for this query; or
+
+ o Validation for this query has been disabled by local policy.
+
+ A security-aware resolver's support for signature verification MUST
+ include support for verification of wildcard owner names.
+
+ A security-aware resolver MUST attempt to retrieve missing DS,
+ DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these
+ RRs in order to perform signature verification.
+
+ A security-aware resolver MUST attempt to retrieve missing a NSEC RR
+ which the resolver needs to authenticate a NODATA response. In
+ general it is not possible for a resolver to retrieve missing NSEC
+ RRs, since the resolver will have no way of knowing the owner name of
+ the missing NSEC RR, but in the specific case of a NODATA response,
+ the resolver does know the name of the missing NSEC RR, and must
+ therefore attempt to retrieve it.
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 19]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ A security-aware resolver MUST be able to determine whether or not it
+ should expect a particular RRset to be signed. More precisely, a
+ security-aware resolver must be able to distinguish between three
+ cases:
+
+ 1. An RRset for which the resolver is able to build a chain of
+ signed DNSKEY and DS RRs from a trusted starting point to the
+ RRset. In this case, the RRset should be signed, and is subject
+ to signature validation as described above.
+
+ 2. An RRset for which the resolver knows that it has no chain of
+ signed DNSKEY and DS RRs from any trusted starting point to the
+ RRset. This can occur when the target RRset lies in an unsigned
+ zone or in a descendent of an unsigned zone. In this case, the
+ RRset may or may not be signed, but the resolver will not be able
+ to verify the signature.
+
+ 3. An RRset for which the resolver is not able to determine whether
+ or not the RRset should be signed, because the resolver is not
+ able to obtain the necessary DNSSEC RRs. This can occur when the
+ security-aware resolver is not able to contact security-aware
+ name servers for the relevant zones.
+
+ A security-aware resolver MUST be capable of being preconfigured with
+ at least one trusted public key, and MUST be capable of being
+ preconfigured with multiple trusted public keys or DS RRs. Since a
+ security-aware resolver will not be able to validate signatures
+ without such a preconfigured trusted key, the resolver SHOULD have
+ some reasonably robust mechanism for obtaining such keys when it
+ boots.
+
+ A security-aware resolver SHOULD cache each response as a single
+ atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
+ single atomic entry containing the entire answer, including the named
+ RRset and any associated DNSSEC RRs. The resolver SHOULD discard the
+ entire atomic entry when any of the RRs contained in it expire.
+
+ A security-aware resolver SHOULD NOT cache data with invalid
+ signatures under normal circumstances. However, a security-aware
+ resolver SHOULD take steps to rate limit the number of identical
+ queries it generates, which may require the resolver to retain some
+ data about recently generated queries. Conceptually, this is similar
+ to negative caching [RFC2308], but since the resolver has no way of
+ obtaining the appropriate caching TTL from received data in this
+ case, the TTL will have to be set by the implementation. This
+ document refers data retained as part of such a rate limiting
+ mechanism as the "BAD cache".
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 20]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+4.1 Recursive Name Servers
+
+ As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
+ recursive name server is an entity which acts in both the
+ security-aware name server and security-aware resolver roles. This
+ section uses the terms "name server side" and "resolver side" to
+ refer to the code within a security-aware recursive name server which
+ implements the security-aware name server role and the code which
+ implements the security-aware resolver role, respectively.
+
+ A security-aware recursive name server MUST NOT attempt to answer a
+ query by piecing together cached data it received in response to
+ previous queries that requested different QNAMEs, QTYPEs, or
+ QCLASSes. A security-aware recursive name server MUST NOT use NSEC
+ RRs from one negative response to synthesize a response for a
+ different query. A security-aware recursive name server MUST NOT use
+ a previous wildcard expansion to generate a response to a different
+ query.
+
+ The name server side of a security-aware recursive name server MUST
+ pass the sense of the CD bit to the resolver side along with the rest
+ of an initiating query, so that the resolver side will know whether
+ whether or not it is required to verify the response data it returns
+ to the name server side.
+
+ The resolver side of a security-aware recursive name server MUST set
+ the DO bit when sending requests, regardless of the state of the DO
+ bit in the initiating request received by the name server side. If
+ the DO bit in an initiating query is not set, the name server side
+ MUST strip any authenticating DNSSEC RRs from the response, but but
+ MUST NOT strip any DNSSEC RRs that the initiating query explicitly
+ requested.
+
+ The resolver side MUST follow the usual rules for caching and
+ negative caching which would apply to any security-aware resolver.
+
+ If the name server side receives a query which matches an entry in
+ the resolver side's BAD cache, the name server side's response
+ depends on the setting of the CD bit in the original query. If the
+ CD bit is set, the name server side SHOULD return the data from the
+ BAD cache; if the CD bit is not set, the name server side SHOULD
+ return RCODE 2 (server failure).
+
+ The name server side of a security-aware recursive name server MUST
+ NOT set the AD bit in a response unless the name server considers all
+ RRsets in the Answer or Authority sections of the response to be
+ authentic, and SHOULD set the AD bit if and only if the name server
+ considers all RRsets in the Answer section and any relevant negative
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 21]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ response RRs in the Authority section to be authentic. How the name
+ server side of a security-aware recursive name server determines
+ whether an RRset is authentic depends on the origin of the RRset. If
+ the RRset came from the resolver side of the recursive name server
+ (the normal case), recursive name server MUST follow the procedure
+ described in Section 5. If the RRset came from a zone for which the
+ name server side of the recursive name server is authoritative, local
+ policy MAY consider the RRset to be authentic without further
+ verification simply because the RRset came from an authoritative
+ zone, but the name server SHOULD NOT do so unless the it obtained the
+ authoritative zone via secure means (such as a secure zone transfer
+ mechanism), and MUST NOT do so unless this behavior has been
+ configured explicitly.
+
+4.2 Stub resolvers
+
+ A security-aware stub resolver MUST include an EDNS [RFC2671] OPT
+ pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
+
+ A security-aware stub resolver MUST support a message size of at
+ least 1220 octets, SHOULD support a message size of 4000 octets, and
+ MUST advertise the supported message size using the "sender's UDP
+ payload size" field in the EDNS OPT pseudo-RR. A security-aware stub
+ resolver MUST handle fragmented UDP packets correctly regardless of
+ whether any such fragmented packets were received via IPv4 or IPv6.
+ Please see [RFC3226] for discussion of these requirements.
+
+ A security-aware stub resolver MUST support the DNSSEC RR types, at
+ least to the extent of not mishandling responses just because they
+ contain DNSSEC RRs. A security-aware stub resolver MAY include the
+ DNSSEC RRs returned by a security-aware recursive name server as part
+ of the data that it the stub resolver hands back to the application
+ which invoked it but is not required to do so.
+
+ A security-aware stub resolver SHOULD NOT set the CD bit when sending
+ queries, since, by definition, a security-aware stub resolver does
+ not validate signatures and thus depends on the security-aware
+ recursive name server to perform validation on its behalf.
+
+ A security-aware stub resolver MAY chose to examine the setting of
+ the AD bit in response messages that it receives in order to
+ determine whether the security-aware recursive name server which sent
+ the response claims to have cryptographically verified the data in
+ the Answer and Authority sections of the response message. Note,
+ however, that the responses received by a security-aware stub
+ resolver are heavily dependent on the local policy of the
+ security-aware recursive name server, so as a practical matter there
+ may be little practical value to checking the status of the AD bit
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 22]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ except perhaps as a debugging aid. In any case, a security-aware
+ stub resolver MUST NOT place any reliance on signature validation
+ allegedly performed on its behalf except when the security-aware stub
+ resolver obtained the data in question from a trusted security-aware
+ recursive name server via a secure channel.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 23]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+5. Authenticating DNS Responses
+
+ In order to use DNSSEC RRs for authentication, a security-aware
+ resolver requires preconfigured knowledge of at least one
+ authenticated DNSKEY or DS RR. The process for obtaining and
+ authenticating this initial DNSKEY or DS RR is achieved via some
+ external mechanism. For example, a resolver could use some off-line
+ authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR
+ that identifies and authenticates a zone's DNSKEY RR. The remainder
+ of this section assumes that the resolver has somehow obtained an
+ initial set of authenticated DNSKEY RRs.
+
+ An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
+ RRset. To authenticate an apex DNSKEY RRset using an initial key,
+ the resolver MUST:
+
+ 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
+ RRset, and verify that the DNSKEY RR has the Zone Key Flag
+ (DNSKEY RDATA bit 7) set to one.
+
+ 2. Verify that there is some RRSIG RR which covers the apex DNSKEY
+ RRset, and that the combination of the RRSIG RR and the initial
+ DNSKEY RR authenticates the DNSKEY RRset. The process for using
+ an RRSIG RR to authenticate an RRset is described in Section 5.3.
+
+ Once the resolver has authenticated the apex DNSKEY RRset using an
+ initial DNSKEY RR, delegations from that zone can be authenticated
+ using DS RRs. This allows a resolver to start from an initial key,
+ and use DS RRsets to proceed recursively down the DNS tree obtaining
+ other apex DNSKEY RRsets. If the resolver were preconfigured with a
+ root DNSKEY RR, and if every delegation had a DS RR associated with
+ it, then the resolver could obtain and validate any apex DNSKEY
+ RRset. The process of using DS RRs to authenticate referrals is
+ described in Section 5.2.
+
+ Once the resolver has authenticated a zone's apex DNSKEY RRset,
+ Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
+ DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
+ RRsets in the zone. Section 5.4 shows how the resolver can use
+ authenticated NSEC RRsets from the zone to prove that an RRset is not
+ present in the zone.
+
+ When a resolver indicates support for DNSSEC, a security-aware name
+ server should attempt to provide the necessary DNSKEY, RRSIG, NSEC,
+ and DS RRsets in a response (see Section 3). However, a
+ security-aware resolver may still receive a response which that lacks
+ the appropriate DNSSEC RRs, whether due to configuration issues such
+ as a security-oblivious recursive name server which accidentally
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 24]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ interfere with DNSSEC RRs or due to a deliberate attack in which an
+ adversary forges a response, strips DNSSEC RRs from a response, or
+ modifies a query so that DNSSEC RRs appear not to be requested. The
+ absence of DNSSEC data in a response MUST NOT by itself be taken as
+ an indication that no authentication information exists.
+
+ A resolver SHOULD expect authentication information from signed
+ zones. A resolver SHOULD believe that a zone is signed if the
+ resolver has been configured with public key information for the
+ zone, or if the zone's parent is signed and the delegation from the
+ parent contains a DS RRset.
+
+5.1 Special Considerations for Islands of Security
+
+ Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
+ zones for which it is not possible to construct an authentication
+ chain to the zone from its parent. Validating signatures within an
+ island of security requires the validator to have some other means of
+ obtaining a trusted zone key. If a validator cannot obtain such a
+ key, it will have to choose whether to accept the unvalidated
+ responses or not based on local policy.
+
+ All the normal processes for validating responses apply to islands of
+ security. The only difference between normal validation and
+ validation within an island of security is in how the validator
+ obtains a trusted starting point for the authentication chain.
+
+5.2 Authenticating Referrals
+
+ Once the apex DNSKEY RRset for a signed parent zone has been
+ authenticated, DS RRsets can be used to authenticate the delegation
+ to a signed child zone. A DS RR identifies a DNSKEY RR in the child
+ zone's apex DNSKEY RRset, and contains a cryptographic digest of the
+ child zone's DNSKEY RR. A strong cryptographic digest algorithm
+ ensures that an adversary can not easily generate a DNSKEY RR that
+ matches the digest. Thus, authenticating the digest allows a
+ resolver to authenticate the matching DNSKEY RR. The resolver can
+ then use this child DNSKEY RR to authenticate the entire child apex
+ DNSKEY RRset.
+
+ Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
+ can be authenticated if all of the following hold:
+
+ o The DS RR has been authenticated using some DNSKEY RR in the
+ parent's apex DNSKEY RRset (see Section 5.3);
+
+ o The Algorithm and Key Tag in the DS RR match the Algorithm field
+ and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 25]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ RRset which, when hashed using the digest algorithm specified in
+ the DS RR's Digest Type field, results in a digest value which
+ matches the Digest field of the DS RR; and
+
+ o The matching DNSKEY RR in the child zone has the Zone Flag bit set
+ to one, the corresponding private key has signed the child zone's
+ apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
+ child zone's apex DNSKEY RRset.
+
+ If the referral from the parent zone did not contain a DS RRset, the
+ response should have included a signed NSEC RRset proving that no DS
+ RRset exists for the delegated name (see Section 3.4). A
+ security-aware resolver MUST query the name servers for the parent
+ zone for the DS RRset if the referral includes neither a DS RRset nor
+ a NSEC RRset proving that the DS RRset does not exist (see Section
+ 4).
+
+ If the resolver authenticates an NSEC RRset which proves that no DS
+ RRset is present for this zone, then there is no authentication path
+ leading from the parent to the child. If the resolver has an initial
+ DNSKEY or DS RR which belongs to the child zone or to any delegation
+ below the child zone, this initial DNSKEY or DS RR MAY be used to
+ re-establish an authentication path. If no such initial DNSKEY or DS
+ RR exists, the resolver can not authenticate RRsets in or below the
+ child zone.
+
+ Note that, for a signed delegation, there are two NSEC RRs associated
+ with the delegated name. One NSEC RR resides in the parent zone, and
+ can be used to prove whether a DS RRset exists for the delegated
+ name. The second NSEC RR resides in the child zone, and identifies
+ which RRsets are present at the apex of the child zone. The parent
+ NSEC RR and child NSEC RR can always be distinguished, since the SOA
+ bit will be set in the child NSEC RR and clear in the parent NSEC RR.
+ A security-aware resolver MUST use the parent NSEC RR when attempting
+ to prove that a DS RRset does not exist.
+
+5.3 Authenticating an RRset Using an RRSIG RR
+
+ A resolver can use an RRSIG RR and its corresponding DNSKEY RR to
+ attempt to authenticate RRsets. The resolver first checks the RRSIG
+ RR to verify that it covers the RRset, has a valid time interval, and
+ identifies a valid DNSKEY RR. The resolver then constructs the
+ canonical form of the signed data by appending the RRSIG RDATA
+ (excluding the Signature Field) with the canonical form of the
+ covered RRset. Finally, resolver uses the public key and signature
+ to authenticate the signed data. Section 5.3.1, Section 5.3.2, and
+ Section 5.3.3 describe each step in detail.
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 26]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+5.3.1 Checking the RRSIG RR Validity
+
+ A security-aware resolver can use an RRSIG RR to authenticate an
+ RRset if all of the following conditions hold:
+
+ o The RRSIG RR and the RRset MUST have the same owner name and the
+ same class;
+
+ o The RRSIG RR's Signer's Name field MUST be the name of the zone
+ that contains the RRset;
+
+ o The RRSIG RR's Type Covered field MUST equal the RRset's type;
+
+ o The number of labels in the RRset owner name MUST be greater than
+ or equal to the value in the RRSIG RR's Labels field;
+
+ o The resolver's notion of the current time MUST be less than or
+ equal to the time listed in the RRSIG RR's Expiration field;
+
+ o The resolver's notion of the current time MUST be greater than or
+ equal to the time listed in the RRSIG RR's Inception field;
+
+ o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
+ match the owner name, algorithm, and key tag for some DNSKEY RR in
+ the zone's apex DNSKEY RRset;
+
+ o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
+ RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
+ set to one.
+
+ It is possible for more than one DNSKEY RR to match the conditions
+ above. In this case, the resolver can not predetermine which DNSKEY
+ RR to use to authenticate the signature, MUST try each matching
+ DNSKEY RR until the resolver has either validated the signature or
+ has run out of matching keys to try.
+
+ Note that this authentication process is only meaningful if the
+ resolver authenticates the DNSKEY RR before using it to validate
+ signatures. The matching DNSKEY RR is considered to be authentic if:
+
+ o The apex DNSKEY RRset containing the DNSKEY RR is considered
+ authentic; or
+
+ o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
+ and the DNSKEY RR either matches an authenticated DS RR from the
+ parent zone or matches a DS RR or DNSKEY RR which the resolver has
+ been preconfigured to believe to be authentic.
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 27]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+5.3.2 Reconstructing the Signed Data
+
+ Once the RRSIG RR has met the validity requirements described in
+ Section 5.3.1, the resolver needs to reconstruct the original signed
+ data. The original signed data includes RRSIG RDATA (excluding the
+ Signature field) and the canonical form of the RRset. Aside from
+ being ordered, the canonical form of the RRset might also differ from
+ the received RRset due to DNS name compression, decremented TTLs, or
+ wildcard expansion. The resolver should use the following to
+ reconstruct the original signed data:
+
+ signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
+
+ "|" denotes concatenation
+
+ RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+ with the Signature field excluded and the Signer's Name
+ in canonical form.
+
+ RR(i) = name | class | type | OrigTTL | RDATA length | RDATA
+
+ name is calculated according to the function below
+
+ class is the RRset's class
+
+ type is the RRset type and all RRs in the class
+
+ OrigTTL is the value from the RRSIG Original TTL field
+
+ All names in the RDATA field are in canonical form
+
+ The set of all RR(i) is sorted into canonical order.
+
+ To calculate the name:
+ let rrsig_labels = the value of the RRSIG Labels field
+
+ let fqdn = RRset's fully qualified domain name in
+ canonical form
+
+ let fqdn_labels = RRset's fully qualified domain name in
+ canonical form
+
+ if rrsig_labels = fqdn_labels,
+ name = fqdn
+
+ if rrsig_labels < fqdn_labels,
+ name = "*." | the leftmost rrsig_label labels of the
+ fqdn
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 28]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ if rrsig_labels > fqdn
+ the RRSIG RR did not pass the necessary validation
+ checks and MUST NOT be used to authenticate this
+ RRset.
+
+ Section 5.5.1 gives an example of original name calculation. The
+ canonical forms for names and RRsets are defined in
+ [I-D.ietf-dnsext-dnssec-records].
+
+ NSEC RRsets at a delegation boundary require special processing.
+ There are two distinct NSEC RRsets associated with a signed delegated
+ name. One NSEC RRset resides in the parent zone, and specifies which
+ RRset are present at the parent zone. The second NSEC RRset resides
+ at the child zone, and identifies which RRsets are present at the
+ apex in the child zone. The parent NSEC RRset and child NSEC RRset
+ can always be distinguished since only the child NSEC RRs will
+ specify an SOA RRset exists at the name. When reconstructing the
+ original NSEC RRset for the delegation from the parent zone, the NSEC
+ RRs MUST NOT be combined with NSEC RRs from the child zone, and when
+ reconstructing the original NSEC RRset for the apex of the child
+ zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
+ zone.
+
+ Note also that each of the two NSEC RRsets at a delegation point has
+ a corresponding RRSIG RR with an owner name matching the delegated
+ name, and each of these RRSIG RRs is authoritative data associated
+ with the same zone which contains the corresponding NSEC RRset. If
+ necessary, a resolver can tell these RRSIG RRs apart by checking the
+ Signer's Name field.
+
+5.3.3 Checking the Signature
+
+ Once the resolver has validated the RRSIG RR as described in Section
+ 5.3.1 and reconstructed the original signed data as described in
+ Section 5.3.2, the resolver can attempt to use the cryptographic
+ signature to authenticate the signed data, and thus (finally!)
+ authenticate the RRset.
+
+ The Algorithm field in the RRSIG RR identifies the cryptographic
+ algorithm to generate the signature. The signature itself is
+ contained in the Signature field of the RRSIG RDATA, and the public
+ key to used generate the signature is contained in the Public Key
+ field of the matching DNSKEY RR(s) (found in Section 5.3.1).
+ [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
+ and provides pointers to the documents that define each algorithm's
+ use.
+
+ Note that it is possible for more than one DNSKEY RR to match the
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 29]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ conditions in Section 5.3.1. In this case, the resolver can only
+ determine which DNSKEY RR by trying each matching key until the
+ resolver either succeeds in validating the signature or runs out of
+ keys to try.
+
+ If the Labels field of the RRSIG RR is not equal to the number of
+ labels in the RRset's fully qualified owner name, then the RRset is
+ either invalid or the result of wildcard expansion. The resolver
+ MUST verify that wildcard expansion was applied properly before
+ considering the RRset to be authentic. Section 5.3.4 describes how
+ to determine whether a wildcard was applied properly.
+
+ If other RRSIG RRs also cover this RRSIG RR, the local resolver
+ security policy determines whether the resolver also needs to test
+ these RRSIG RRs, and determines how to resolve conflicts if these
+ RRSIG RRs lead to differing results.
+
+ If the resolver accepts the RRset as authentic, the resolver MUST set
+ the TTL of the RRSIG RR and each RR in the authenticated RRset to a
+ value no greater than the minimum of:
+
+ o The RRset's TTL as received in the response;
+
+ o The RRSIG RR's TTL as received in the response; and
+
+ o The value in the RRSIG RR's Original TTL field.
+
+
+5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
+
+ If the number of labels in an RRset's fully qualified domain name is
+ greater than the Labels field in the covering RRSIG RDATA, then the
+ RRset and its covering RRSIG RR were created as a result of wildcard
+ expansion. Once the resolver has verified the signature as described
+ in Section 5.3, the resolver must take additional steps to verify the
+ non-existence of an exact match or closer wildcard match for the
+ query. Section 5.4 discusses these steps.
+
+ Note that the response received by the resolver should include all
+ NSEC RRs needed to authenticate the response (see Section 3.3).
+
+5.4 Authenticated Denial of Existence
+
+ A resolver can use authenticated NSEC RRs to prove that an RRset is
+ not present in a signed zone. Security-aware name servers should
+ automatically include any necessary NSEC RRs for signed zones in
+ their responses to security-aware resolvers.
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 30]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ Security-aware resolvers MUST first authenticate NSEC RRsets
+ according to the standard RRset authentication rules described in
+ Section 5.3, then apply the NSEC RRsets as follows:
+
+ o If the requested RR name matches the owner name of an
+ authenticated NSEC RR, then the NSEC RR's type bit map field lists
+ all RR types present at that owner name, and a resolver can prove
+ that the requested RR type does not exist by checking for the RR
+ type in the bit map. Since the existence of the authenticated
+ NSEC RR proves that the owner name exists in the zone, wildcard
+ expansion could not have been used to match the requested RR owner
+ name and type.
+
+ o If the requested RR name would appear after an authenticated NSEC
+ RR owner name and before the name listed in that NSEC RR's Next
+ Domain Name field according to the canonical DNS name order
+ defined in [I-D.ietf-dnsext-dnssec-records], then no exact match
+ for the requested RR name exists in the zone. However, it is
+ possible that a wildcard could be used to match the requested RR
+ owner name and type, so proving that the requested RRset does not
+ exist also requires proving that no possible wildcard exists which
+ could have been used to generate a positive response.
+
+ To prove non-existence of an RRset, the resolver must be able to
+ verify both that the queried RRset does not exist and that no
+ relevant wildcard RRset exists. Proving this may require more than
+ one NSEC RRset from the zone. If the complete set of necessary NSEC
+ RRsets is not present in a response (perhaps due to truncation), then
+ a security-aware resolver MUST resend the query in order to attempt
+ to obtain the full collection of NSEC RRs necessary to verify
+ non-existence of the requested RRset. As with all DNS operations,
+ however, the resolver MUST bound the work it puts into answering any
+ particular query.
+
+ Since a verified NSEC RR proves the existance of both itself and its
+ corresponding RRSIG RR, a verifier MUST ignore the settings of the
+ NSEC and RRSIG bits in an NSEC RR.
+
+5.5 Examples
+
+ Editors' note: perhaps all of this should move to an appendix?
+
+
+5.5.1 Example of Re-Constructing the Original Owner Name
+
+ Suppose that a security-aware resolver receives a response containing
+ an answer RRset with an owner name of is "www.a.b.c.example.com".
+ This fully qualified domain name has 6 labels: "www", "a", "b", "c",
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 31]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ "example", and "com". What name the resolver should use when
+ reconstructing the original signed data depends on the value of the
+ RRSIG RR's Labels field.
+
+ If the value of the RRSIG RR's Labels field is 6, then the RRSIG RR's
+ Labels field matches the number of labels in the owner name, and the
+ resolver should assume that this RRset is not the result of wildcard
+ expansion. The resolver should therefore use "www.a.b.c.example.com"
+ as the owner name when reconstructing the original signed data for
+ the signature check.
+
+ If the value of the RRSIG RR's Labels field is less than 6, then the
+ RRSIG RR's Labels count is less than the number of labels in the
+ RRset's owner name, and the resolver should assume that this RRset is
+ the result of wildcard expansion. The resolver should therefore
+ reconstruct the original owner name by replacing the labels which
+ appear to be the result of wildcard expansion with a single "*."
+ label. For example, if the RRSIG RR's Labels field is 3, the
+ resolver should reconstruct the original owner name by prepending
+ "*." to the last 3 labels of the owner name of the answer RRset.
+ Thus, the resolver should use "*.c.example.com" as the owner name
+ when reconstructing the original signed data.
+
+ If the value of the RRSIG RR's Labels field is greater than 6, then
+ this RRSIG RR cannot possibly be valid for the answer RRset, and
+ there is no point in attempting to validate the signature.
+
+5.5.2 Examples of Authenticating a Response
+
+ Editors' note: Eventually this will be an example of the
+ authentication process for "www.example.com", starting from an
+ initial root key.
+
+ Editors' note: Eventually this will be an example of the
+ authentication process for non-existent "www.a.b.c.example.com",
+ starting from an initial root key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 32]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+6. IANA Considerations
+
+ [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
+ considerations introduced by DNSSEC. The additional IANA
+ considerations discussed in this document:
+
+ [RFC2535] reserved the CD and AD bits in the message header. The
+ meaning of the AD bit was redefined in [I-D.ietf-dnsext-ad-is-secure]
+ and the meaning of both the CD and AD bit are restated in this
+ document. No new bits in the DNS message header are defined in this
+ document.
+
+ [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
+ and defined its use. The use is restated but not altered in this
+ document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 33]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+7. Security Considerations
+
+ This document describes how the DNS security extensions use public
+ key cryptography to sign and authenticate DNS resource record sets.
+
+ DNSSEC introduces a number of denial of service issues. These issues
+ will also be addressed in a future version of these security
+ considerations.
+
+ Please see [I-D.ietf-dnsext-dnssec-intro] for general security
+ considerations related to DNSSEC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 34]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+8. Acknowledgements
+
+ This document was created from the input and ideas of several members
+ of the DNS Extensions Working Group and working group mailing list.
+ The co-authors of this draft would like to express their thanks for
+ the comments and suggestions received during the revision of these
+ security extension specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 35]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+ August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+ 3225, December 2001.
+
+ [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+ message size requirements", RFC 3226, December 2001.
+
+ [I-D.ietf-dnsext-dnssec-intro]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-06 (work in progress),
+ September 2003.
+
+ [I-D.ietf-dnsext-dnssec-records]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Resource Records for DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-04 (work in progress),
+ September 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 36]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+Informative References
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [I-D.ietf-dnsext-delegation-signer]
+ Gudmundsson, O., "Delegation Signer Resource Record",
+ draft-ietf-dnsext-delegation-signer-15 (work in progress),
+ June 2003.
+
+ [I-D.ietf-dnsext-wcard-clarify]
+ Halley, B. and E. Lewis, "Clarifying the Role of Wild Card
+ Domains in the Domain Name System",
+ draft-ietf-dnsext-wcard-clarify-01 (work in progress),
+ August 2003.
+
+ [I-D.ietf-dnsext-ad-is-secure]
+ Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD
+ bit", draft-ietf-dnsext-ad-is-secure-06 (work in
+ progress), June 2002.
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Drienerlolaan 5
+ 7522 NB Enschede
+ NL
+
+ EMail: roy.arends@telin.nl
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 37]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: mlarson@verisign.com
+
+
+ Rob Austein
+ Internet Software Consortium
+ 40 Gavin Circle
+ Reading, MA 01867
+ USA
+
+ EMail: sra@isc.org
+
+
+ Dan Massey
+ USC Information Sciences Institute
+ 3811 N. Fairfax Drive
+ Arlington, VA 22203
+ USA
+
+ EMail: masseyd@isi.edu
+
+
+ Scott Rose
+ National Institute for Standards and Technology
+ 100 Bureau Drive
+ Gaithersburg, MD 20899-8920
+ USA
+
+ EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 38]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+Appendix A. Algorithm For Handling Wildcard Expansion
+
+ For zone (Z) and a name (N) that may occur in Z, the following
+ algorithm finds all wildcard RRsets that match N or returns an NSEC
+ RRset that proves no wildcard expansion matches N. The algorithm was
+ written for clarity, not efficiency:
+
+ 0. INPUT: a name (N) and a zone (Z).
+ INIT: NSEC_SET = NULL
+
+ 1. Construct S = sequence of all names in Z, sorted
+ into canonical order.
+
+ 2. If N exists in S
+ There is an exact match for N.
+ Return all RRsets associated with N
+ Else
+ Add the name that would immediately
+ precede N in S to NSEC_SET.
+ EndIf
+
+ 3. Replace the leftmost label of N with *
+
+ 4. If N exists in S and answers the query
+ There is a positive wildcard match for N.
+ Return all RRsets associated with N
+ Else
+ Add the NSEC for name that would immediately
+ precede N in S to NSEC_SET.
+ Return the NSEC_SET.
+ EndIf
+
+ 5. Remove the leading * from N.
+
+ 6. If N exists in S
+ There is a name that terminates the wildcard search.
+ Add the NSEC for N to NSEC_SET and return NSEC_SET.
+ Else
+ Add the NSEC for name that would immediately
+ precede N in S to NSEC_SET.
+ Return the NSEC_SET.
+ EndIf
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 39]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+Appendix B. Signed Zone Example
+
+ The following example shows a (small) complete signed zone.
+
+ example. 3600 IN SOA ns1.example. bugs.ns1.example. (
+ 1064876255
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ 3600 RRSIG SOA 1 1 3600 20031029215736 (
+ 20030929215736 4638 example.
+ Bo6PBV6UOrnCzptCZg0lTQQqsZ4qqIn16vbA
+ KQobYD2wNxs5hxNYlvNRlNPB0nfSD9o2daBE
+ v0Q/Q5mEanr2R28a62PHwkHNwHUx/spGWAGJ
+ h5u28d5wMNQQvMsFgB+kSSnNEcL1Z7uLjRal
+ ahgGvtiSMzzSS7n65xfxc1X78Nw= )
+ 3600 NS ns1.example.
+ 3600 NS ns2.example.
+ 3600 RRSIG NS 1 1 3600 20031029215736 (
+ 20030929215736 4638 example.
+ WeJdApmzK+GIrOQKYmkABF5POWu5SDU6opwd
+ wOjWrVFGRNhFHe1Z/KZwT1Ii5YjH2X9dTRRh
+ YG3U/wcqvWLJ1882FoUZakwmtzGFotdONcs3
+ DzhFMxTawVlBb+MLsPj8J2GuZiR28eTyPB6i
+ TYq3Ed0R9VStJwtiKmoXqubFAr0= )
+ 3600 MX 1 xx.example.
+ 3600 RRSIG MX 1 1 3600 20031029215736 (
+ 20030929215736 4638 example.
+ eBXNS2Vi/MhqX76VCIlpbK4yq9UWzvYcSBV9
+ Cx0t6rl9CWOpdFVzV/lL0wyVYQjZXBlZ1gpo
+ djLXl0QTEE+9MrRO3c8j7NyVsOEJQdnWdEAW
+ BL8f+F3fwayjj5dIsq1NngF8neGXROao1bJM
+ 5gmIc/F6gzUL3/KyJA8zPF2fUVA= )
+ 3600 NSEC a.example. NS SOA MX RRSIG NSEC
+ 3600 RRSIG NSEC 1 1 3600 20031029215736 (
+ 20030929215736 4638 example.
+ t3VabTtmQ3uEgohzbuHKk2bFEDqYWa3hgTi2
+ D1Sv+eN+IkV1xExBvsvuE6Oovf+QlDqV7sU/
+ XP2kRzob5V9N40xQCZMBFx2GgAim8px788EX
+ ZuS7u0fKeHfaP/2sSTktGnpK77Mx4fM6RK8x
+ DBRONckIWXn2chGDeicQuEHjhfQ= )
+ 3600 DNSKEY 256 3 1 (
+ AQPbGuRKgswzNd2Qb7ck1Tdai9FFbapP3mUO
+ G80mSowM5s9aMao+JOeFl/4f33cs2hWHznn3
+ LZ5EuIlA/lvvG+f5h46OvCR+CFXHmqEPyMmd
+ kiCdJmHcvRuMIzekHM2DSDcG7i1lZG/jXvaG
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 40]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ mK5G3NeHjqssh1AujDaqHFf5IRIeQQ==
+ )
+ 3600 DNSKEY 257 3 1 (
+ AQPGkQLwyHHfD8nkDxZSbErTBHLYdOKkVIoq
+ SJkBnpfABtFdiJBgZYcjCNExAFjlc/olW42g
+ TJYBRjs1INw3I08/h43L595Iq8fyhEyBoGOR
+ +6db+Q3oQ9G2EKpfMEPDLU6f7gYrHpzDHIjO
+ rsSftzmRYHou70oVQ7aBjd9ePPCOVw==
+ )
+ 3600 RRSIG DNSKEY 1 1 3600 20031029215736 (
+ 20030929215736 4638 example.
+ GMZI2r4bwFYpKIs0Dv//4aWg5HhpzMBkm5Vk
+ 4KFg4hEkOabYgWoBJdZdjRBTrjwkrtiPH9KF
+ kJKlzFfeeELbFEfhgZ3SujDqNQmGfoZ1i7a2
+ lH47jc1JOeos75e9QK8fUFjIxOF8fkZNO9Fx
+ lOyOxNDJPATE3Wm+AX0SmQSJ3XY= )
+ a.example. 3600 IN NS ns1.a.example.
+ 3600 IN NS ns2.a.example.
+ 3600 DS 23677 1 1 (
+ F248F32298280A061736C93FB078A51C17CC
+ C291 )
+ 3600 RRSIG DS 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ k6fA3VfeR5UHu9L/+4y8HJrUubVHBdyFzMaa
+ 8EpDYqw3vYEVsrL5YvXwoqrSZsSAxdIrUXoB
+ SzjbKFOq6HRxXjuLsJ2TLT90p6mg9ZHL57jH
+ FfmrNPuq58QwRWvwuOyaExJWEdxMIEIbvETz
+ YJs3G/9tNte9i25YtAuLHbD2UqY= )
+ 3600 NSEC ai.example. NS DS RRSIG NSEC
+ 3600 RRSIG NSEC 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ tQbGVL6yxb2vBQ5ItcQ1XQyxNxz3+zHTTkgs
+ T/WSk9YXr+swug7h+Wq20RPXfsEl7lVMi/By
+ d60s6Q7lEibGucIQCLLx0Xe68zQOmWx7fmU6
+ iSDTQgc7TOsG/blDba7MiRENTeI6iynyZHw9
+ gURpK8RlfEPb7O98rrYLWZbzg3o= )
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+ ai.example. 3600 IN A 192.0.2.9
+ 3600 RRSIG A 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ UCegsbGngHOwgyxevtBrCSsV6Jv6OxGWApvY
+ RsbwL2XZBFc4saU6Zujiz8i2urkVLSlFM2MM
+ OHuEMN5E+cjGDjqfaI8O5eILapsGRqHUPM9t
+ 5wCOb9BqANn03UUFUhAnKBkv3fHFM5hg+IZQ
+ vVNUzslGEBlQ0SJZkWJcCtRDo5c= )
+ 3600 HINFO "KLH-10" "ITS"
+ 3600 RRSIG HINFO 1 2 3600 20031029215736 (
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 41]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ 20030929215736 4638 example.
+ CP6bRkIyQ3FnhsBWO63uQN1QtJse8mWNRTf2
+ jXqR33dekEfKNhlQtw0yzepa7lX75uyQTAlP
+ NBBK73Zlim5g1bw3ulLl0vXnTpQRSK80SJw9
+ uPPTYBDq68jMKn1a3RvGnR5MynQR33UY2vGT
+ 6IAiGfqY/zYFXWSIsmJr0875PQ0= )
+ 3600 AAAA 2001:db8::f00:baa9
+ 3600 RRSIG AAAA 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ VnpRe+HGt+mCalDopO4wtHtRvs9CKdjr3FoG
+ zv8BPFvC1FdDJAjxpAgJs6Ihx+174Hl+jlZU
+ Z3HOd0MBwch0XH1UDcU0/opQRquW+oYwV3E4
+ esgKhsy9EUj3NtoW/GQ/1dJEbuUZah4/IPGH
+ KI0DhRWJC/iKs6J963WLNdPnwKk= )
+ 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
+ 3600 RRSIG NSEC 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ A7MtS+oATUFf6t3nj/0GL7lBbt86ozzkbbJM
+ J3tLwFkGebf1XV+MnpPeSzeRXm4QeqohDvVZ
+ U5SluyOHT397x4WQPwHCRXojos1lQnWhPUji
+ qjKaXLVRHv4x2O2fzWu0OE65GJkL6zAnFqCL
+ SpV8hBOC+EAcLjnuAi5DJJlONmc= )
+ b.example. 3600 IN NS ns1.b.example.
+ 3600 IN NS ns2.b.example.
+ 3600 NSEC ns1.example. NS RRSIG NSEC
+ 3600 RRSIG NSEC 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ lGZ+rJ1vtIEtLjXKG4Iruipq6KoXrre89QHZ
+ dBgSPcomROrsSElhUBFLcl2+KMCnKCqtEJZ7
+ YPOTK07WCwFU6Rek+xD+OuuJrQRWTbiCmFMX
+ N9ZMk87lkIWHAXMk1YM3f1/FUytbb8RI8RfH
+ u2x/e3zoBQdHAId3LCOO9jYDzCc= )
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+ ns1.example. 3600 IN A 192.0.2.1
+ 3600 RRSIG A 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ u/uV4xcu7KSVV+3Vtg8O0qTGlGHeFKU1vBQJ
+ x1QKLtolw/ZstzqIuRBI5fuF4JYxSwMoaI7b
+ JBFyZ3KkCCK88r1VjZTkicNvFG7RO3G2faxb
+ MualMbGfhcexJzRcoZsIXSb3+qtbAr4aKF7c
+ fdZ587NLR1Ns2GraGTztUDMSK/A= )
+ 3600 NSEC ns2.example. A RRSIG NSEC
+ 3600 RRSIG NSEC 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ bsz0NVY6tQ0kmIpKOR3QHNEradwR39uNikey
+ jQIr7TMOvNVDX6tVBNoDuKxUy6zHR5CS6oBs
+ nN5OPPKEjTdOGWUfHavSZgZGT7b8xfL++Ahi
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 42]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ Cgeg0ofB6Ext7KfeMkTrxP/8BsDMJm8R8Ome
+ I2mIq/WvuXTr2XKcJDbxYIdSyss= )
+ ns2.example. 3600 IN A 192.0.2.2
+ 3600 RRSIG A 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ mCzjw1wydcnYx0d7kbPbJTXVw+FnksdLnTmq
+ DrIdy269MeGL4AGJSV8g8Gt0Zbq3hGo6+/Tz
+ S9VIp4QZtKgRZ1nlI0XQOlkASOLPjvo7hHRr
+ PPiFqGyznqy9+QHdIalqTO4BOrfS3f5bIgJW
+ IGUMRh8nFi+wnG09+OH46IlkB9s= )
+ 3600 NSEC *.w.example. A RRSIG NSEC
+ 3600 RRSIG NSEC 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ FS6W/8Na26DIs1DYB1Xhhxc1GyRlzj5XkG/3
+ pY6H6PQGc/nP6CVM1eHEkmvYAG8kWfk9ZdDZ
+ 64cOb2tisSH1o7WMLg7hWUS5nnXyxyyj5/Gs
+ n3CpVCDptq9JnQe+jjH0empKdbTYoeVIX8h/
+ 2aw1RkmYb4LbuhP0uwN/lZqQVik= )
+ *.w.example. 3600 IN MX 1 ai.example.
+ 3600 RRSIG MX 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ MHxP6z3ozpA9AICDnEW0T06o2GlIOtj0+oGm
+ TC4nqveQj2QSKOEUNXgVaUkBTT9F/FIVy9q+
+ FAAe4SXnBcVpIvTVN2NhU4Jm9976hU8HTEfi
+ EMlnhmn4vJ1qZ+DI1WgWK+iKSU/N6ShdN/Fi
+ G7zd/X4PmuWIIYG+5IAzmtB2UJs= )
+ 3600 NSEC x.w.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ tXBqjlbdFl70S+dzovir86EQBHavroozeo4f
+ Spsc9BlorSdTTSwbf7lh+GRIS0hCtaJxMFog
+ 0XhGhO6sn1Yai3s7NeV6viQpy8gPfJ0wfr9Y
+ H1nYv76o6oXX2KlGTJrd4J7f7Hxz2DsOWVoK
+ w1LXOATBvP/kCRgmq4KdFNwTiBc= )
+ x.w.example. 3600 IN MX 1 xx.example.
+ 3600 RRSIG MX 1 3 3600 20031029215736 (
+ 20030929215736 4638 example.
+ p/BQOuDk4Wg3pZreH6kmxws0A1hNYIkJTTlP
+ rHoI9T/HMfA50p/qnXQHxgYh1IDnsxjeswaE
+ LL7B/q0QxmaT1/0wNbZTn58/rqDSpV43Qxjl
+ QHK0fDgp6al4VNxvK+uIJIHO525jCH146BEC
+ +tqUhrmtTxtItfpV/8Q7i6+B2bY= )
+ 3600 NSEC x.y.w.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 1 3 3600 20031029215736 (
+ 20030929215736 4638 example.
+ c2/unp4ewGHNJIOVKiw9O/aA+PfXJ5Thwjt4
+ EyleUaXFp01H5RkDVxMVicJEHcfslqfzF8XP
+ M9pPTwU7DPAFrxXo71pMez/EqA3pnhxnUcEi
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 43]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ lVextpfIxIZam0Oj5Q+nCLJJs95Q3I8E5J29
+ IgHVoBYahu8hE0DycgzLredhC5A= )
+ x.y.w.example. 3600 IN MX 1 xx.example.
+ 3600 RRSIG MX 1 4 3600 20031029215736 (
+ 20030929215736 4638 example.
+ nwe5rxko6mbV2f0edTn0/H1CbDd8T4ZHg2Wg
+ Os3Lh5Rz092PVbAnbzCp4Y95MdPPwMUd3cKk
+ h7tvjBJgPPBhAWufdv2uVcq2lnINs1+LsJH7
+ CtJobsu9LxcORCkcYEKG1bc4fInPPnuUnlXD
+ JYEmK1UOpYTDRx+lKLRI5tLzKmc= )
+ 3600 NSEC xx.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 1 4 3600 20031029215736 (
+ 20030929215736 4638 example.
+ UjlRFPbR2LzHtiP+CDGsJnaSo0iyooOkZ2By
+ vyqOGHg+0OudJ4/+VYC/8C0dJNRUzAAm17GG
+ ox272n3P0BHERCeegWAFCjYCARhZwkfpq8sQ
+ ynkJRjpFlkxgdSFiHDZOAQz/s0a9ZaFDKP27
+ rKbS4qvhL+dfOnPBPNI099W7EAw= )
+ xx.example. 3600 IN A 192.0.2.10
+ 3600 RRSIG A 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ irvnPlRadiUTTM3feA/mNNKnxRIRY7vZ0r3d
+ foc+IgbvYJeHi8UYThPrinjF2SPcwQ29g+6h
+ aFA8ne9ZpRwL1lEQ6U3OTGLKd1OtGCTizEmN
+ fgmPU/wIUuNaR7AG4i6FekWhciHbrjfRF/NN
+ zJKlxAUeVRQ2ufYCoSY7wa6cIV4= )
+ 3600 HINFO "KLH-10" "TOPS-20"
+ 3600 RRSIG HINFO 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ NL6VSnSkuPX41EgJChuPiVF9JzIsJ/p7pQ61
+ DG8oWhtZjTP1uYWdwHPMM3EDxQykJBwJShE9
+ 5Mg7myUpRFAuLHZJZ35227AZ6+eo0UoikJSA
+ opuXW50OLYARZTy4lRqSUU41B5Km1vvYaIoq
+ hjNlRggyhvEmSNw4kvl5w99jqKg= )
+ 3600 AAAA 2001:db8::f00:baaa
+ 3600 RRSIG AAAA 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ wkkCfIYfNeQ2YK0fL/bceo9oONGfZNkp/MnQ
+ yllq11xEoelJbWjqlS7RbfUViOVbrxJbV+8j
+ AYnLEC3/YGdoDUeVBPk2hqfGB8vMZfsu/d1Y
+ bhcMej6fIoXj/q4HIXNSD9UcP0CNtLR6n7Bq
+ ndtF5V/pM6xI0tiE51KudVttsJI= )
+ 3600 NSEC example. A HINFO AAAA RRSIG NSEC
+ 3600 RRSIG NSEC 1 2 3600 20031029215736 (
+ 20030929215736 4638 example.
+ fi2La99VLlZhIPUgGd/Fd6MH8wJZ6ziSPW34
+ k214lDIQQBlu0X4V0z4DcZ/PDBeqvKOORmEI
+ AhZLwELtWv5XSAmALYUr3Rrtp/H066R4EpAu
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 44]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ YrS4pZ8/QFM+HnPUcofSK3IzLBucXsnDSYr0
+ fQ5nfoBQ++eHo+IEohbqrwnE60E= )
+
+ The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
+ Flags indicate that each of these DNSKEY RRs is a zone key. One of
+ these DNSKEY RRs also has the SEP flag set and has been used to sign
+ the apex DNSKEY RRset; this is the key which should be hashed to
+ generate a DS record to be inserted into the parent zone. The other
+ DNSKEY is used to sign all the other RRsets in the zone.
+
+ The zone includes a wildcard entry "*.w.example". Note that the name
+ "*.w.example" is used in constructing NSEC chains, and that the RRSIG
+ covering the "*.w.example" MX RRset has a label count of 2.
+
+ The zone also includes two delegations. The delegation to
+ "b.example" includes an NS RRset, glue address records, and an NSEC
+ RR; note that only the NSEC RRset is signed. The delegation to
+ "a.example" provides a DS RR; note that only the NSEC and DS RRsets
+ are signed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 45]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). 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 assignees.
+
+ 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
+
+
+
+Arends, et al. Expires March 30, 2004 [Page 46]
+\f
+Internet-Draft DNSSEC Protocol Modifications September 2003
+
+
+ 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 March 30, 2004 [Page 47]
+\f
projects / thirdparty / bind9.git / commitdiff
