From 1095647f93d84c71b1e5fee024aa161a32135cbc Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 6 Mar 2003 20:52:58 +0000 Subject: [PATCH] new draft --- .../draft-ietf-dnsext-dnssec-protocol-00.txt | 1792 ------------- .../draft-ietf-dnsext-dnssec-protocol-01.txt | 2296 +++++++++++++++++ 2 files changed, 2296 insertions(+), 1792 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-protocol-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-protocol-01.txt diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-00.txt deleted file mode 100644 index ec6790bfb5..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-00.txt +++ /dev/null @@ -1,1792 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft -Expires: April 25, 2003 M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - October 25, 2002 - - - Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-00 - -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 April 25, 2003. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document is part of a family of documents that describe the - DNS Security Extensions (DNSSEC). The DNS Security Extensions are - a collection of new resource records and protocol modifications - that provide source authentication for the DNS. This document - describes the DNSSEC protocol modifications. The concept of zone - - - -Arends, et al. Expires April 25, 2003 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - signing is introduced and the zone format is modified to include - KEY, SIG, NXT, and DS resource records. If a resolver indicates - support for DNSSEC, the response process is modified to include - the appropriate KEY, SIG, NXT, and DS resource records. These - resource records are used by the resolver to authenticate the - response. - - 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 . . . . . . . . . . . . . . 5 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. Zone Signing and Zone Format . . . . . . . . . . . . . . . . 6 - 2.1 Inclusion of KEY RRs in a Zone . . . . . . . . . . . . . . . 7 - 2.2 Inclusion of NXT RRs in a Zone . . . . . . . . . . . . . . . 7 - 2.3 Inclusion of SIG RRs in a Zone . . . . . . . . . . . . . . . 7 - 2.4 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 - 2.5 Inclusion of DS RRs in a Zone . . . . . . . . . . . . . . . 8 - 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 - 3. Constructing DNS Responses . . . . . . . . . . . . . . . . . 10 - 3.1 Indicating Resolver Support for DNSSEC . . . . . . . . . . . 10 - 3.2 Inclusion of SIG RRs in a Response . . . . . . . . . . . . . 11 - 3.3 Inclusion of KEY RRs In a Response . . . . . . . . . . . . . 12 - 3.4 Inclusion of NXT RRs In a Response . . . . . . . . . . . . . 12 - 3.4.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12 - 3.4.2 Case 2: Query Name Does Not Exist and No Wildcard Matches . 13 - 3.4.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13 - 3.5 Inclusion of DS RRs In a Response . . . . . . . . . . . . . 13 - 3.6 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13 - 3.7 Special Considerations for Recursive/Caching Servers . . . . 15 - 3.8 Setting the AD and CD Bits in a Response . . . . . . . . . . 15 - 3.9 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16 - 4. Authenticating DNS Responses . . . . . . . . . . . . . . . . 17 - 4.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 18 - 4.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 19 - 4.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 19 - 4.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 20 - 4.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 22 - 4.2.4 Authenticating Wildcard Expanded RRset . . . . . . . . . . . 23 - 4.3 Authenticated Denial of Existence . . . . . . . . . . . . . 23 - 4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - - - -Arends, et al. Expires April 25, 2003 [Page 2] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 4.4.1 Example of Re-Constructing the Original Name . . . . . . . . 24 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 - 6. Security Considerations . . . . . . . . . . . . . . . . . . 27 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - References . . . . . . . . . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 - A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 31 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 32 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 25, 2003 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 1. Introduction - - The DNS Security Extensions (DNSSEC) modify several aspects of the - DNS protocol. The concept of zone signing is introduced and the - zone format is modified to include KEY, SIG, NXT, and DS resource - records as described in Section 2. If the resolver has indicated - support for DNSSEC, the process of constructing a DNS response is - also modified to include the appropriate KEY, SIG, NXT, and DS RR - types. Section 3 defines how a resolver indicates support for - DNSSEC, describes how the DNSSEC RR types are included in a - response, and also describes the specgal processing rules required - to handle queries for the DS RR type. Finally, Section 4 defines - how a resolver uses the DNSSEC RRs to authenticate a response. - - 1.1 Background and Related Documents - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication the Domain Name System (DNS). An - introduction to DNSSEC and definition of common terms can be found - in [8]. A definition of the DNSSEC resource records can be found - in [9]. This document defines the DNSSEC protocol modificatinos. - - The reader to assumed to be familiar with the basic DNS concepts - described in RFC1034 [1] and RFC1035 [2] and should also be - familiar with common DNSSEC terminology as defined in [8]. - - 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 - - The use of the NXT record requires input from the working group. - Although the opt-in issue is not resolved, progress on this - document was still needed. 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 opt-in is adopted. - - The use of the AD bit is described in section 3.8 and requires - input from the working group. Since the AD bit usage is not - - - -Arends, et al. Expires April 25, 2003 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 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. 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 there is no RFC that - defines the correct behavior (or RFCs provide conflicting - answers), 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 quickly find the incorrect text. - - 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 April 25, 2003 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 2. Zone Signing and Zone Format - - DNSSEC defines a new process called zone signing and adds the KEY, - SIG, NXT, and DS resource records to the zone format. The zone - signing process is the first step in enabling resource record - authentication for this zone. After a signed zone has been - created and loaded, the KEY, SIG, NXT, and DS resource records can - be included in responses (as decribed in Section 3) and can be - used by resolvers to authenticate responses (as describe in - Section 4). KEY, SIG, NXT, and DS RRs MUST NOT appear in unsigned - zones. - - To sign a zone, the zone administrator generates one or more - public/private key pairs. The zone's public key(s) are made - available by storing them in KEY resource records. Other DNS - public keys, such as public keys used by TKEY and SIG(0), can also - be stored in KEY RRs. Once the KEY records have been added to the - zone, the zone is sorted into a canonical form and NXT resource - records are added to enable authenticated denial of existence. - The zone administrator then signs every authoritative RRset in the - zone using the private key(s) and the signatures are stored in SIG - resource records. The resulting signed zone contains all data in - the original (unsigned) zone and also includes the new KEY, NXT, - and SIG RRs. - - Section 2.1, Section 2.2, and Section 2.3 present the rules for - the including the KEY, NXT, and SIG resource records in a zone - (respectively). - - The zone signing process also requires a change in the definition - of the CNAME resource record and Section 2.4 changes the CNAME RR - to allow SIG and NXT RRs to appear along with the CNAME RR. - - To enable authentication chains between DNS zones, a signed zone - includes DS Resource Records for its signed delegations. Section - 2.5 presents the rules for including DS resource records. - - Note that if a resource record in a signed zone is added, - modified, or deleted, the signatures associaates with this RRset - MUST be updated and the NXT RR associated with the RRset's owner - name MUST also be updated. In addition, the zone MUST be - periodically resigned in order to maintain current SIG expiration - dates and the zone keys SHOULD change periodically. DNSSEC best - practices documents are encouraged to provide recommendations for - signature and key lifetimes. - - - - - - -Arends, et al. Expires April 25, 2003 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 2.1 Inclusion of KEY RRs in a Zone - - A zone administrator generates a set of public/private key pairs - and uses the private key(s) to sign authoritative RRsets in the - zone. For each private zone key used to create SIG RRs, there - SHOULD be a corresponding public KEY RR stored at the zone apex - and the corresponding KEY RR MUST have the Zone Key Flag (KEY - RDATA Flag bit 7) set to 1. KEY RR's with Zone Flag set MUST only - appear at the zone apex. - - A signed zone MUST have at least one zone KEY RR in its apex KEY - set and the apex KEY set MUST be self-signed by at least one - private key whose corresponding public zone KEY RR is stored in - the apex KEY set. - - Other DNS public keys, such as those used by TKEY and SIG, can be - stored in the zone using non-Zone KEY RR's (KEY RDATA Flag bit 7 - set to 0). Non-zone KEY RR's MUST NOT appear at delegation names, - but MAY appear at any other authoritative name in the zone. A - non-zone KEY RR SHOULD NOT appear at the apex name since this - could lead to large apex KEY sets and requires added processing - time at resolvers. - - 2.2 Inclusion of NXT RRs in a Zone - - Each authoritative name in the zone MUST have an NXT resource - record. The NXT record indicates what are RR types are present at - that name and indicates the next authortitive name in the zone. - The collection of NXT or "next" resource records (RR) provide a - chain of all authoritative names and RRsets in the zone and are - used for authenticated denial of existence. The process for - constructing the NXT RR for a given name is described in [9]. - - 2.3 Inclusion of SIG RRs in a Zone - - For each authoritative RRset in the zone, there MUST be at least - one SIG record that meets all of the following requirements: - - The SIG owner name is equal to the RRset owner name. - - The SIG class is equal to the RRset class. - - The SIG Type Covered field is equal to the RRset type. - - The SIG Original TTL field is greater than or equal to the TTL - of the RRset. - - The SIG Labels field is equal to the number of labels in RRset - - - -Arends, et al. Expires April 25, 2003 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - owner name. - - The SIG Signer's Name is equal to the name of the zone - containing the RRset. - - The SIG Algorithm, Signer's Name, and Key Tag fields identify a - zone KEY record at the zone apex. - - The process for constructing the SIG RR for a given RRset is - described in [9]. An RRset MAY have multiple SIG RR associated - with it. - - The SIG RR itself MUST NOT be signed since signing a SIG RRset - adds no value and creates a unterminated dependency loop in the - signing process. - - The NS RRset that appears at the zone apex name MUST be signed, - but NS RRsets that appear at delegation owner names (child zones) - MUST NOT be signed and any glue address RRsets assoicated with - child delegations MUST NOT be signed. - - 2.4 Changes to the CNAME Resource Record. - - If a CNAME RR is present at a name, RRs other than the SIG and NXT - MUST NOT be present at that name. - - The above is modification to the original CNAME definition given - in [1]. The original definition of CNAME did not allow any other - resource records to co-exist with a CNAME record, but the zone - signing process associates NXT and SIG resource records with every - authorititative name. To resolve this conflict, the definition of - the CNAME resource record is modified to allow for the co- - existence of NXT and SIG RRs. - - 2.5 Inclusion of DS RRs in a Zone - - The DS resource record is used to establish authentication chains - between DNS zones. A signed delegation (child zone) SHOULD - provide its parent zone with a DS RR for the delegation. All DS - RRsets stored in a zone MUST be signedx and DS RRsets MUST NOT - appear at non-delegation points or at a zone's apex. - - The DS RR provided by the child SHOULD point to a KEY RR that is - present in the child's apex KEY set and the child's apex KEY RRset - SHOULD be signed by the corresponding private key. If the KEY RR - is present in the child's apex KEY set, the KEY RR MUST have the - Zone Key Flag set. - - - - -Arends, et al. Expires April 25, 2003 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - Note that the process of providing a DS RR can be accomplished by - either directly sending the DS RR to the parent or by sending a - KEY RR to the parent and requesting that the parent construct a DS - RR for the given KEY RR. The parent/child communication needs to - be authenticated in order to prevent an adversary from inserting a - false DS RR. DNSSEC operational and best practices documents are - encouraged to provide guidelines for providing a DS RR. - - 2.6 Example of a Secure Zone - - secure 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 set 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 and this KEY and might be used by - SIG(0) to authenticate transactions from this host. - - The zone includes a wildcard entry *.a.example.com. Note the - *.a.example.com name is used in constructing NXT chains and the - SIG covering the *.a.example.com MX RRset has a label count of 3. - - The zone also includes two delegations. The delegation to - unsecure.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 has provided a DS RR and note that - only NXT and DS RRsets are signed. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 25, 2003 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 3. Constructing DNS Responses - - Unless a resolver has indicated support for DNSSEC, no changes are - made to the standard (non-secure) DNS response and a server simply - behaves as if no DNSSEC RR types were present. This helps avoid - backwards compatability issues and also avoids increasing the size - of (non-secure) DNS responses. Servers MUST NOT include any - DNSSEC RR types (KEY NXT SIG DS) unless the resolver has indicated - support for DNSSEC using one of the mechanisms described in - Section 3.1. - - If a resolver has indicated support for DNSSEC: - - SIG RRs that can be used to authenticate a response are - automatically included in the response according to the rules - in Section 3.2. - - NXT RRs that can be used to provide authenticated denial of - existence are automatically included in the response according - to the rules in Section 3.4. - - DS RRs (or an NXT RR if DS RRs are present) are automatically - included in referals according to the rules in Section 3.5. - - Since the DS RR is the only RR type that appears only on the - upper side of a delegation, any query for the DS RR type - requires special processing as described in Section 3.6. - - Section 3.7 discusses how these changes impact caching servers and - recursive servers. - - 3.1 Indicating Resolver Support for DNSSEC - - A resolver has indicated it supports DNSSEC if any of the - following hold: - - The query explictly requests a KEY, NXT, SIG, or DS RR type. - - The query implicitly requests a KEY, NXT, SIG, or DS by - requesting a meta-type that matches the KEY, SIG, NXT, or DS - RRs. In particular, ANY, IXFR, and AFXR queries implictly - match the DNSSEC RR types and DNSSEC RRs MUST be returned in - response to a query for ANY, IFXR, or AXFR. - - The resolver has explicity requested DNSSEC by setting the - DNSSEC OK bit in the ENDS0 header. - - The "DNSSEC OK" (D0) bit is used for explicit notification of - - - -Arends, et al. Expires April 25, 2003 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - DNSSEC support. The DO bit is defined in [9] and setting the DO - bit to one in a query indicates that the resolver is able to - accept DNSSEC security RRs. The DO bit cleared (set to zero) - indicates the resolver is unprepared to handle DNSSEC security RRs - and those RRs MUST NOT be returned in the response (unless DNSSEC - security RRs are explicitly requested in the query or implicitly - requested by the use a meta-RR type such as ANY, IXFR, or AFXR). - The DO bit of the query MUST be copied in the response. - - In the event a server returns a NOTIMP, FORMERR or SERVFAIL - response to a query that has the DO bit set, the resolver SHOULD - NOT expect DNSSEC security RRs and SHOULD retry the query without - EDNS0 in accordance with Section 5.3 of RFC2671 [6]. - - The absence of DNSSEC data in response to a query with the DO bit - set MUST NOT be taken to mean no security information is available - for that zone since the response may have be forged or may be a - non-forged response to an altered (DO bit cleared) query. - - 3.2 Inclusion of SIG RRs in a Response - - If the resolver has indicated support for DNSSEC, servers SHOULD - attempt to send SIG RRs that can be used to authenticate the RR - sets in the response. The inclusion of SIG RRs in a response is - subject to the following rules: - - When an signed RRset is placed in the answer section, its SIG - RRs are also placed in the answer 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. - - When an 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. - - When an 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. - - - - - - - - -Arends, et al. Expires April 25, 2003 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 3.3 Inclusion of KEY RRs In a Response - - If the resolver has indicated support for DNSSEC and the query - requests the SOA or NS RRs, then a server SHOULD return the KEY - RRset with the same name in the additional section. If not all - additional information will fit in the response, type A and AAAA - glue RRs have higher priority than KEY RRs. The SIG RR(s) - associated with the KEY RR set SHOULD also be included in the - additional section (see including SIG RRs in Section 3.2). - - 3.4 Inclusion of NXT RRs In a Response - - If the resolver has indicated support for DNSSEC, the server MUST - include NXT RRs in each of the following cases: - - Case 1: the query name exists, but the requested RR type does - not exist. - - 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 answer the query. - - NXT RRs are also included in a referal response if no DS RR is - present. In this case, the NXT RR is used to prove no DS RR - exists for the delegation and referals are discussed in detail in - Section 3.5. - - Note that in every case the NXT RRs are included to provide - authenticated denial of existence. - - 3.4.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 - including SIG RRs in Section 3.2) If space does not permit the - inclusion of the NXT RR (or its associate SIG RRs), the response - MUST be considered truncated. - - Note that since the query name exists, an single NXT RR suffices - to prove the requested type does not exist. Since the name exists - in the zone, an NXT RR for that name also exists and lists RR - types present at the name. Since the query name exists, no - wildcard expansion applies to this query. - - - - -Arends, et al. Expires April 25, 2003 [Page 12] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 3.4.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, the authority section of the response MUST include an - NXT RR that proves there was no exact match for the name and MUST - also include NXT RRs that prove no wildcard would have matched the - query. Any SIG(s) associated with the NXT RRsets are also - included in the authority section (see including SIG RRs in - Section 3.2) If space does not permit the inclusion of these NXT - RRs, the response MUST be considered truncated. - - Appendix A provides an algorithm for computing the appropriate NXT - RRs that prove no wildcard matches the query name. - - 3.4.3 Case 3: Query Name Does Not Exist, but Wildcard Matches - - If the query name does not exist and a wildcard expansion matches - the query, then the wildcard card expanded answer (and any SIG RRs - associated with the wildcard RR) are returned in the answer - section. The authority section of the response MUST include NXT - RRs that prove there were no exact matches for the name and MUST - also include NXT RRs to prove no closer wildcard entry would have - matched this query. - - Appendix A provides an algorithm for computing the appropriate NXT - RRs that prove no closer wildcard matches the query name. - - 3.5 Inclusion of DS RRs In a Response - - If the resolver has indicated support for DNSSEC, a server - returning a referral for the delegation MUST include both the NS - RRset and DS RRset if the DS RRset exists. The NS RRset MUST be - placed before the DS RRset (and its assoicated SIG RRs). - - If the resolver has indicated support for DNSSEC, a server - returning a referral for the delegation MUST include both parent - NS RRset and the parent NXT RR if the DS RRset does not exist. - The NS RRset MUST be placed before the NXT RRset (and its - assoicated SIG RRs). - - 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 RRset (NXT RRset) and its assoicated SIG RRs, - the response MUST be considered truncated. - - 3.6 Responding to Queries for DS RRs - - The DS record is the first resource record that appears only on - - - -Arends, et al. Expires April 25, 2003 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - the upper side of a delegation. In other words, the DS record for - zone "example.com" is only stored in the "com" zone (the parent/ - upper side of the delegation). This introduces novel server - behavior since the child server is authoritative for the zone, but - the zone does not contain the DS RR. A server's response to a DS - query depends on whether the server is authoritative for the - parent and/or child zones as described below. - - If a server is authoritative for the parent zone at a delegation - point and receives a query for the DS record at the delegation - name, then the server MUST return the DS RRset from the parent - zone. This is true regardless of whether or not the server is - also authoritative for the child zone. - - If the server is authoritative for the child zone at a delegation - point and is not authoritative for the parent zone, there is no - natural response. The child zone is not authoritative for the DS - record at the zone's apex and the DS RR is only stored at the - parent. - - If the server allows recursion and the RD bit is set in the - query, the server MAY perform recursion to find the DS record - at the delegation point and MAY return the DS record from its - cache. In this case, the AA bit MUST NOT be set in the - response. - - If the server does not perform recursion to find the DS RR, - the server MUST reply with: - - RCODE: NOERROR - AA bit: set - Answer Section: Empty - Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] - - In other words, an authortative child server answers as if it is - authoritative for the zone and the DS record does not exist. Note - DS-aware recursive servers will query the parent zone at - delegation points and thus will not be affected by this behavior. - - For example, suppose "example.com" is a delegation point and a - query for the "example.com" DS RRset is received by a server. - - If the server is authoritative for "com", the server MUST - reply with the "example.com" DS RRset from the "com" zone. - - If the server is authoritative for "example.com" and is not - authortative for "com", the server MAY perform recursion to - find the "example.com" DS record (provided the RD bit was set - - - -Arends, et al. Expires April 25, 2003 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - in the query). If the server does not use recursion to obtain - the DS RR, the 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.7 Special Considerations for Recursive/Caching Servers - - A DNSSEC aware recursive server MUST set the DO bit on recursive - requests, regardless of the status of the DO bit on the initiating - resolver request. If the initiating resolver request does not - have the DO bit set, the recursive DNSSEC-aware server MUST remove - any DNSSEC security RRs before returning the data to the client, - however cached data MUST NOT be modified. - - A caching server SHOULD NOT attempt to answer a query by piecing - together the responses it has received previous from other queries - that requested different names or RR types. A cache typically - does not have access to the complete zone and thus it can be - difficult for a caching server to determine the proper SIG, NXT, - KEY, and DS RRs for a given a query. A caching server SHOULD - cache each response single atomic entry indexed by the question - (including the response and the all the assoicated DNSSEC RR - types). The cache SHOULD discard the entire entry when any RR in - the response expires. - - 3.8 Setting the AD and CD Bits in a Response - - DNSSEC allocates two new bits in the DNS message header section: - The CD (checking disabled) bit and the AD (authentic data) bit. - These bits are defined in [9] and their use is described below. - - The CD bit is set by the resolver and MUST be copied in the - response. If the CD bit is set to one, it indicates the resolver - is willing to perform authentication and the server need not - perform authentication on the RRsets in the response. - - Regardless of the CD bit, the server MAY choose to perform - authentication (or choose not to perform authentication) according - to the local server policy. The CD bit MAY be used in - constructing the local server policy. If local 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). - - - -Arends, et al. Expires April 25, 2003 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - The AD bit is set by the server and indicates the data in the - response has been authenticated by the server, according to the - local 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 servers local authentication policy. A resolver MUST NOT - use the AD bit unless unless it communicates with the server over - a secure transport mechanism and is explicitly configured to trust - the server's policy. DNSSEC best practices documents are - encouraged to provide server policy recommendations. - - 3.9 Example DNSSEC Responses - - example of A and SIG - - example of apex KEY - - example of signed delegation (DS) and unsigned delegation (NXT) - - example of auth denial (includes NXT for wildcards) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 25, 2003 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 4. Authenticating DNS Responses - - In order to use DNSSEC RRs for authentication, a resolver requires - some intial 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. In the - remainder of this section assumes the resolver has used some - unspecified off-line mechanism and 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 the initial KEY RR appears in the apex KEY RRset and - verify the KEY RR has the Zone Key Flag (KEY RDATA bit 7) set - to 1. - - 2. Verify there is some SIG RR that covers the apex KEY RRset - and the combination of the SIG RR and the initial KEY RR - authenticate the KEY RRset. The process for using a SIG RR to - authenticate an RRset is described in Section 4.2. - - Once the apex KEY RRset has been authenticated using an initial - KEY RR, delegations from that zone can be authenticated using DS - RRs. This allows a resolver to start from an initial externally - authenticated key, and use DS RRsets to recursively proceed down - the DNS tree to obtain other apex KEY RRsets. If the resolver was - initially configured with a root KEY RR and if every delegation - had a DS RR assoicated with it, the resolver could obtain any apex - KEY RRset. The process of using DS RRs to authentic a referal is - described in Section 4.1. - - Once a zones apex KEY RRset has been authenticated, Section 4.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 4.3 shows how the resolver can use authenticated - NXT RRsets from the zone to prove an RRset is not present in the - zone. - - If the resolver has indicated support for DNSSEC, DNSSEC aware - servers SHOULD attempt to provide the necessary KEY, SIG, NXT, and - DS RRets in a response (see Section 3). However, a response that - lacks the approriate DNSSEC RRs may result from configuration - issues such as a non-DNSSEC aware cache that removes or fails - request DNSSEC RRs or may result from an intentional attack where - - - -Arends, et al. Expires April 25, 2003 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - an adversary forges a response, strips DNSSEC RRs from a response - forges, or modifies the query so DNSSEC RRs appear not to be - requested. The absence of DNSSEC data in response MUST NOT be - taken to mean that no authentication information is available. - - A resolver SHOULD expect authentication information from signed - zones. A SHOULD believe 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 at the parent contains - a DS RRset. DNSSEC best practices documents are encouraged to - provide guidance on how a resolver responds if DNSSEC RRs are - expected, but can not be obtained. DNSSEC best practices - documents are also are encouraged to provide guidance on how a - resolver responds if the expected DNSSEC RRs are obtained but - appear invalid (e.g. all SIG RRs are expired). - - 4.1 Authenticating Referrals - - Once the apex KEY RRset for a (parent) zone has been - authenticated, DS RRsets can be used to authenticate a referal to - a delegation (child zone). A DS RR identifies a KEY RR in the - child's apex KEY RRset. The DS RR contains a digest of the - child's KEY RR and 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 - safely declare the matching child KEY RR to is also authentic. - This child KEY RR is then used to authenticate the entire child - apex KEY RRset. - - Given a DS RR for a delegation (child zone), the delegation's - (child zone's) apex KEY RRset is considered to be authentic if all - of the following hold: - - The DS RR has been authenticated using some KEY RR in the - parent's apex KEY RRset (see Section 4.2). - - The Algorithm, Key Tag, and Digest fields in the DS RR match - the algorithm, key tag, and digest of a KEY RR present in the - child's apex KEY RRset. - - The matching KEY RR in the child zone has the Zone Flag bit set - to one, the corresponding private key has signed the child apex - KEY RRset, and the resulting SIG RR authenticates the child's - apex KEY RRset. - - If the referal from the parent zone did not contain a DS RRset, - the response SHOULD have included an NXT RRset that proves no DS - RRset exists for the delegation name (see Section 3.5). A - - - -Arends, et al. Expires April 25, 2003 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - resolver SHOULD send the parent a query for the DS RRset if - neither a DS RRset or NXT RRset is included in the referal. - - If the resolver authenticates an NXT RRset that proves 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 KEY RR that belongs to the child zone (or 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 for a signed delegation there are two NXT RRs associated with - the delegation name. One NXT RR resides at the parent can be used - to prove whether a DS RRset exists for the delegation name. A - second NXT RR resides at the child zone and identifies which - RRsets are present at the apex in the child zone. The parent NXT - RR and child NXT RR can always be distinguished since the only the - child NXT RR will specify an SOA RR set exists at the name. A - resolver MUST only use the parent NXT RR when proving a DS RRset - does not exist. - - 4.2 Authenticating an RRSet Using a SIG RR - - A SIG RR (and its corresponding KEY RR) is used by a resolver to - authentic an RRset. The SIG RR is first checked to verify that it - covers the RRset, has a valid time interval, and identifies a - valid KEY RR. The signed data is then constructed by appending - SIG RDATA (excluding the Signature Field) with the covered RRset - (in canonical form). Finally, the public key and signature and - used to authenticate the signed data. Section 4.2.1, Section - 4.2.2, and Section 4.2.3 describe each step in detail. - - 4.2.1 Checking the SIG RR Validity - - An SIG RR can be used to authenicate an RRset if all of the - following conditions hold: - - The SIG RR and the RRset MUST have the same owner name and same - class. - - The SIG RR's Signer's Name field MUST be the name of the zone - that contains the RRset. - - The SIG RR's Type Covered field MUST equal the RRset's type. - - 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. - - - -Arends, et al. Expires April 25, 2003 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - The resolver's current time MUST be less than or equal to the - time listed in the SIG RR's Expiration field. - - The resolver's current time MUST be greater than or equal to - the time listed in the SIG RR's Inception field. - - 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. - - 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 1. - - It is possible that more than one KEY RR matches the conditions - above. In this case, the resolver can not determine which KEY RR - is used to authenticate the signature and the resolver MUST try - each matching KEY RR until the resolver has either validated the - signature or all matching KEY RRs have failed. - - Note that the authentication process is only meaningful if the - resolver first authenticates a KEY RR before using it to validate - a signature. The matching KEY RR is considered to be authentic if - - The apex KEY RRset containing the KEY RR is considered - authentic - - The RRset covered by the SIG RR is the apex KEY RRset itself - and the KEY RR matches an authenticated DS RR from the parent - zone or matches some initial KEY RR/DS RR that is known to be - authentic. - - - 4.2.2 Reconstructing the Signed Data - - Once the SIG RR has met the validity requirements described in - Section 4.2.1, the original signed data needs to be reconstructed. - The original signed data includes SIG RDATA (excluding the - Signature field) and the RRset in cannonical order and might - differ from the RRset received in the DNS response due to name - compression, TTL decrementing by a cache, or the RRset may be the - result of wildcard expansion. The following algorithm is used to - reconstuct the original signed data: - - signed_data = SIG_RDATA | RR(1) | RR(2)... where - - "|" denotes append - - - - -Arends, et al. Expires April 25, 2003 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - SIG_RDATA is the wire format of the SIG RDATA fields with - the Signature field excluded. - the Signer's Name in cannonical 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 SIG Original TTL field - - All names in the RDATA field are in canonical form - - The set of all RR(i) is sorted into cannonical 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. - - An example of original name calculation is given in Section 4.4.1. - The canonical form for names and RRsets is defined in [9]. - - NXT RRsets present at a delegaion name require special processing. - There are two distinct NXT RRsets associated with a signed - delegation name. One NXT RRset resides at the parent and - specifies which RRset are present at the parent. A 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 RR set exists at the name. When - - - -Arends, et al. Expires April 25, 2003 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - constructing the original NXT RRset, the NXT RRs MUST NOT be - combined with NXT RRs from the child (and vice versa). - - 4.2.3 Checking the Signature - - Once the SIG RR has met the validity requirements described in - Section 4.2.1 and the original signed data has been reconstructed - as described in Section 4.2.2, the cryptographic signature is used - to authenticate the signed data (and thus authenticate the RRset). - - The Algorithm field in the SIG RR identifies the cryptographic - algorithm used to validate the signature. The signature itself is - contained in the Signature field of the SIG RDATA and public key - used to authenticate this signature is contained in the Public Key - field of the matching KEY RR(s) (found in Section 4.2.1). [9] - provides a list of algorithm types and provides pointers to the - documents that define each algorithm's use. - - Note it is possible that more than one KEY RR matches the - conditions in Section 4.2.1. In this case, the resolver can not - determine which KEY RR is used to authenticate the signature and - the resolver MUST try each matching KEY RR until the resolver has - either validated the signature or all matching KEY RRs have - failed. - - If the SIG RR Labels field is not equal to the number of labels in - the RRsets fully qualified domain name, then the RRset is a result - of wildcard expansion. The resolver MUST verify the wildcard was - applied properly before the RRset is considered authentic. The - RRset and SIG RR MUST be discarded if the resolver proves the - wildcard was applied improperly. Section 4.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 these SIG RRs need to be tested - and determines how to resolve conflicts if these SIG RRs lead to - differing results. - - If the RRset is accepted as authentic, the SIG RR TTL and the TTL - of each RR in the authenticated RRset MUST be set to the minimum - of - - the RR TTL received in the response - - the value in the SIG RRs Original TTL field - - - - - - -Arends, et al. Expires April 25, 2003 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 4.2.4 Authenticating Wildcard Expanded RRset - - If a SIG RR's fully qualified domain name does not equal the - Labels field in the SIG RDATA, then SIG RR (and its covered RRset) - were created as a result of wildcard expansion. Once the - signature has been verified as described in Section 4.2, - additional steps are required to verify 1) no intermediate name - cancels the use of the wildcard and 2) no more specific wildcard - name could have been used to create this RRset. - - Intermediate label names can be formed from the fully qualified - domain name by removing the rightmost labels and are used to prove - the wildcard was used properly. For example, - "www.a.b.c.example.com." has intermediate names of - "a.b.c.example.com", "b.c.example.com", "c.example.com", - "example.com", and "com". For each intermediate label name whose - label count is greater the SIG RR Labels field, the resolver MUST - obtain and authenticate NXT RRs that prove: - - the intermediate label name does not exist (otherwise this - label would cancel the wildcard) - - the name "*.intermediate_label_name" does not exist (otherwise - this wildcard would take precedence) - - Note the response SHOULD include all NXT RRs needed to the - authenticate the response (see Section Section 3.4). - - 4.3 Authenticated Denial of Existence - - A resolver can use authenticated NXT RRs to prove that an RRset is - not present in a signed zone. NXT RRsets SHOULD be automatically - included in the response, provided the zone is signed and the - resolver has indicated support for DNSSEC. NXT RRsets are - authenticated according to standard RRset authentication rules - described in Section 4.2 and are applied as follows: - - If the requested RR name matches the owner name of an - authenticated NXT RR, then all RR types present at that owner - name MUST be listed in the NXT RR's Type Bit Map field. A - resolver can prove the requested RR type does not exist by - presenting checking for the RR type in NXT RR's Type Bit Map - field. Also, since owner name exists in the zone, no wildcard - expansion could be used to match the requested RR owner name and - type. - - If the requested RR name logically appears after an authenticated - NXT RR owner name and logically appears before the name listed in - - - -Arends, et al. Expires April 25, 2003 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - that NXT RR's Next Domain Name field, then the requested RR name - is not present in the zone. However, it is possible a wildcard - could be used to match the requested RR owner name and type - - Intermediate label names are used to prove no wildcard matches the - requested name. Intermediate label names are formed from the - requested RR's fully qualified domain name by removing the - rightmost labels from the name. For example, - "www.a.b.c.example.com." has intermediate names of - "a.b.c.example.com", "b.c.example.com", "c.example.com", - "example.com", and "com". To prove no wildcard matches, the - resolver MUST start with the longest intermediate label name prove - that: - - No wildcard exists at this intermediate label name. In other - words, there is an authenticated NXT RR such the NXT RR's owner - name logically appears before "*.intermediate_label_name" and - the NXT RR's Next Domain field appears logically after - "*.intermediate_lable_name". - - The resolver MUST continue testing intermediate label names until - (in order of decreasing label count) until the intermediate label - name matches an authenticated NXT RR's owner name. Note that this - is guaranteed to occur since at some point the intermediate label - will equal the zone name and NXT RR exists at the zone name. - - 4.4 Example - - 4.4.1 Example of Re-Constructing the Original Name - - Suppose the RRset owner name received in a response is - "www.a.b.c.example.com.". This fully qualified domain name has 6 - labels: "www", "a", "b", "c", "example", and "com". The name - used in reconstructing the original signed data depends on the - value of the SIG Labels. - - If the SIG Labels field is 6, then the SIG Labels field equals the - number of labels in the RRsets fully qualified domain name. - Wildcard expansion was not used to construct this RRset and the - name "www.a.b.c.example.com." is used to construct the original - signed data. - - If the SIG Labels field is 3, then the SIG Labels field is - strictly less than number of labels in the RRset's fully qualified - domain name. Wildcard expansion was used to construct this RRset - and the original wildcard owner name is constructed by appending - "*." to the last 3 labels in the owner name. The name - "*.c.example.com." is is used to construct the original signed - - - -Arends, et al. Expires April 25, 2003 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - data. - - authentication process for www.example.com starting from a initial - root key - - authentication process for non-existent www.a.b.c.example.com - starting from a initial root key - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 25, 2003 [Page 25] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 5. IANA Considerations - - This document introduces no IANA considerations. - - [9] contains a complete review of the IANA considerations - introduced by the DNSSEC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 25, 2003 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 6. 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. 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 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 the revised version of the - security considerations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 25, 2003 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 7. 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 April 25, 2003 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - -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] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [8] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC - Intro", October 2002. - - [9] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource - Records for the DNS Security Extensions", October 2002. - - -Authors' Addresses - - Roy Arends - Bankastraat 41-E - 1094 EB Amsterdam - NL - - EMail: roy@logmess.com - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - - -Arends, et al. Expires April 25, 2003 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 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 April 25, 2003 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - - 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 - RR set that proves no wildcard expansion matches N. The algorithm - was written for clarity not efficiency: (EDITORS NOTE: the - algorithm was really written on a redeye flight during dull movie - so it is unlikely to really achieve clarity :) - - 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 - preceed N in S to NXT_SET. - EndIf - - 3. Replace the leftmost label of N with * - - 4. If N exists in S - There is a wildcard match for N. - Return all RRsets associated with N - Else - Add the NXT for name that would immediately - preceed N in S to NXT_SET. - EndIf - - 5. Remove the leading * from N. - - 6. If N exists in S - There is an 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 April 25, 2003 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications October 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished - to others, and derivative works that comment on or otherwise - explain it or assist in its implementation may be prepared, - copied, published and distributed, in whole or in part, without - restriction of any kind, provided that the above copyright notice - and this paragraph are included on all such copies and derivative - works. However, this document itself may not be modified in any - way, such as by removing the copyright notice or references to the - Internet Society or other Internet organizations, except as needed - for the purpose of developing Internet standards in which case the - procedures for copyrights defined in the Internet Standards - process must be followed, or as required to translate it into - languages other than English. - - The limited permissions granted above are perpetual and will not - be revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on - an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 25, 2003 [Page 32] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-01.txt new file mode 100644 index 0000000000..2f04c08feb --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-01.txt @@ -0,0 +1,2296 @@ + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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 , 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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] +