diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt new file mode 100644 index 0000000000..1a9f8aaf7a --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt @@ -0,0 +1,3249 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: August 16, 2004 M. Larson + VeriSign + R. Austein + ISC + D. Massey + USC/ISI + S. Rose + NIST + February 16, 2004 + + + Protocol Modifications for the DNS Security Extensions + draft-ietf-dnsext-dnssec-protocol-05 + +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 August 16, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents which describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications which + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + + + +Arends, et al. Expires August 16, 2004 [Page 1] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + defines the concept of a signed zone, along with the requirements for + serving and resolving using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 + 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 + 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6 + 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6 + 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7 + 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 + 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 + 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10 + 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11 + 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11 + 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12 + 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14 + 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16 + 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17 + 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17 + 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20 + 4.3 Determining Security Status of Data . . . . . . . . . . . . 21 + 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 22 + 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 22 + 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22 + 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 23 + 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24 + 4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24 + 4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24 + + + +Arends, et al. Expires August 16, 2004 [Page 2] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + 4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 26 + 5.1 Special Considerations for Islands of Security . . . . . . . 27 + 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 27 + 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 28 + 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29 + 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 30 + 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 31 + 5.3.4 Authenticating A Wildcard Expanded RRset Positive + Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 32 + 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 35 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 + Normative References . . . . . . . . . . . . . . . . . . . . 37 + Informative References . . . . . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . 46 + B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 47 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 48 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 49 + B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 50 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 52 + C. Authentication Examples . . . . . . . . . . . . . . . . . . 54 + C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 54 + C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54 + C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55 + C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 55 + C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 55 + C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 55 + C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56 + C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56 + C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 56 + Intellectual Property and Copyright Statements . . . . . . . 57 + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 3] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications which add data origin + authentication and data integrity to the DNS. This document defines + the DNSSEC protocol modifications. Section 2 of this document defines + the concept of a signed zone and lists the requirements for zone + signing. Section 3 describes the modifications to authoritative name + server behavior necessary to handle signed zones. Section 4 describes + the behavior of entities which include security-aware resolver + functions. Finally, Section 5 defines how to use DNSSEC RRs to + authenticate a response. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034] and RFC1035 [RFC1035]. + + This document is part of a family of documents which define DNSSEC. + An introduction to DNSSEC and definition of common terms can be found + in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC + resource records can be found in [I-D.ietf-dnsext-dnssec-records]. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. [RFC2119]. + +1.3 Editors' Notes + +1.3.1 Open Technical Issues + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + + + + +Arends, et al. Expires August 16, 2004 [Page 4] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +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 August 16, 2004 [Page 5] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to + the rules specified in Section 2.1, Section 2.2, Section 2.3 and + Section 2.4, respectively. A zone that does not include these + records according to the rules in this section is an unsigned zone. + + DNSSEC requires a change to the definition of the CNAME resource + record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG + and NSEC RRs to appear at the same owner name as a CNAME RR. + +2.1 Including DNSKEY RRs in a Zone + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with + the public component stored in the zone. A zone key DNSKEY RR MUST + have the Zone Key bit of the flags RDATA field set to one -- see + Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys + associated with other DNS operations MAY be stored in DNSKEY RRs that + are not marked as zone keys but MUST NOT be used to verify RRSIGs. + + If the zone is delegated and does not wish to act as an island of + security, the zone MUST have at least one DNSKEY RR at the apex to + act as a secure entry point into the zone. This DNSKEY would then be + used to generate a DS RR at the delegating parent (see + [I-D.ietf-dnsext-dnssec-records]). + + DNSKEY RRs MUST NOT appear at delegation points. + +2.2 Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone, there MUST be at least + one RRSIG record that meets all of the following requirements: + + o The RRSIG owner name is equal to the RRset owner name; + + o The RRSIG class is equal to the RRset class; + + o The RRSIG Type Covered field is equal to the RRset type; + + o The RRSIG Original TTL field is equal to the TTL of the RRset; + + o The RRSIG RR's TTL is equal to the TTL of the RRset; + + o The RRSIG Labels field is equal to the number of labels in the + + + +Arends, et al. Expires August 16, 2004 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + RRset owner name, not counting the null root label and not + counting the leftmost label if it is a wildcard; + + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset; and + + o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key DNSKEY record at the zone apex. + + The process for constructing the RRSIG RR for a given RRset is + described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have + multiple RRSIG RRs associated with it. + + An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR + would add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated with + delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the parent zone's DS RRset and each additional + algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset + itself MUST be signed by each algorithm appearing in the DS RRset. + +2.3 Including NSEC RRs in a Zone + + Each owner name in the zone which has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + process for constructing the NSEC RR for a given name is described in + [I-D.ietf-dnsext-dnssec-records]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner names nodes which were + not the owner name of any RRset before the zone was signed. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + The difference between the set of owner names that require RRSIG + + + +Arends, et al. Expires August 16, 2004 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + signed zone to its children. Neither NSEC nor RRSIG records are + present (in the parent zone) at the owner names of glue address + RRsets. Note, however, that this distinction is for the most part is + only visible during the zone signing process, because NSEC RRsets are + authoritative data, and are therefore signed, thus any owner name + which has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + +2.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 public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR which is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (i.e., the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5 Changes to the CNAME Resource Record. + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed. Other types + MUST NOT be present at that name. + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + + + + +Arends, et al. Expires August 16, 2004 [Page 8] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +2.6 Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 9] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +3. Serving + + This section describes the behavior of entities that include + security-aware name server functions. In many cases such functions + will be part of a security-aware recursive name server, but a + security-aware authoritative name server has some of the same + requirements as a security-aware recursive name server does. + Functions specific to security-aware recursive name servers are + described in Section 3.2; functions specific to authoritative servers + are described in Section 3.1. + + The terms "SNAME", "SCLASS", and "STYPE" in the following discussion + are as used in [RFC1034]. + + A security-aware name server MUST support the EDNS0 [RFC2671] message + size extension, MUST support a message size of at least 1220 octets, + and SHOULD support a message size of 4000 octets [RFC3226]. + + A security-aware name server that receives a DNS query that does not + include the EDNS OPT pseudo-RR or that has the DO bit set to zero + MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other + RRset, and MUST NOT perform any of the additional processing + described below. 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.1.4.1. + + 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 controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Section 3.1.6, + Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details + on the behavior of these bits. + +3.1 Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS [RFC2671] OPT + pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative + name server for a signed zone MUST include additional RRSIG, NSEC, + and DS RRs according to the following rules: + + o RRSIG RRs that can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1; + + o NSEC RRs that can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.1.3; + + + +Arends, et al. Expires August 16, 2004 [Page 10] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST + be included in referrals automatically according to the rules in + Section 3.1.4. + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1 Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set to one, a + security-aware authoritative name server SHOULD attempt to send RRSIG + RRs that a security-aware resolver can use to authenticate the RRsets + in the response. Inclusion of RRSIG RRs in a response is subject to + the following rules: + + o When placing a signed RRset in the Answer section, the name server + MUST also place its RRSIG RRs in the Answer section. The RRSIG + RRs have a higher priority for inclusion than any other RRsets + that may need to be included. If space does not permit inclusion + of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Authority section, the name + server MUST also place its RRSIG RRs in the Authority section. + The RRSIG RRs have a higher priority for inclusion than any other + RRsets that may need to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Additional section, the name + server MUST also place its RRSIG RRs in the Additional section. + If space does not permit inclusion of both the RRset and its + associated RRSIG RRs, the name server MUST NOT set the TC bit + solely because these RRSIG RRs didn't fit. + + +3.1.2 Including DNSKEY RRs In a Response + + When responding to a query that has the DO bit set to one and that + requests the SOA or NS RRs at the apex of a signed zone, a + security-aware authoritative name server for that zone MAY return the + zone apex DNSKEY RRset in the Additional section. In this situation, + the DNSKEY RRset and associated RRSIG RRs have lower priority than + any other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + + + +Arends, et al. Expires August 16, 2004 [Page 11] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +3.1.3 Including NSEC RRs In a Response + + When responding to a query that has the DO bit set to one, a + security-aware authoritative name server for a signed zone MUST + include NSEC RRs in each of the following cases: + + No Data: The zone contains RRsets that exactly match , + but does not contain any RRsets that exactly match . + + Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match but does contain an RRset that matches + via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match , does contain one or more RRsets that match + via wildcard name expansion, but does not contain + any RRsets that match via wildcard name + expansion. + + In each of these cases, the name server includes NSEC RRs in the + response to prove that an exact match for was + not present in the zone and that the response that the name server is + returning is correct given the data that are in the zone. + +3.1.3.1 Including NSEC RRs: No Data Response + + If the zone contains RRsets matching but contains no + RRset matching , then the name server MUST + include the NSEC RR for along with its associated + RRSIG RR(s) in the Authority section of the response (see Section + 3.1.1). If space does not permit inclusion of the NSEC RR or its + associated RRSIG RR(s), the name server MUST set the TC bit (see + Section 3.1.1). + + Since the search name exists, wildcard name expansion does not apply + to this query, and a single signed NSEC RR suffices to prove the + requested RR type does not exist. + +3.1.3.2 Including NSEC RRs: Name Error Response + + If the zone does not contain any RRsets matching + either exactly or via wildcard name expansion, then the name server + MUST include the following NSEC RRs in the Authority section, along + with their associated RRSIG RRs: + + + +Arends, et al. Expires August 16, 2004 [Page 12] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + o An NSEC RR proving that there is no exact match for ; and + + o An NSEC RR proving that the zone contains no RRsets that would + match via wildcard name expansion. + + In some cases a single NSEC RR may prove both of these points, in + that case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + Note that this form of response includes cases in which SNAME + corresponds to an empty non-terminal name within the zone (a name + which is not the owner name for any RRset but which is the parent + name of one or more RRsets). + +3.1.3.3 Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets which exactly match but does contain an RRset which matches via wildcard name expansion, the name server MUST include the + wildcard-expanded answer and the corresponding wildcard-expanded + RRSIG RRs in the Answer section, and MUST include in the Authority + section an NSEC RR and associated RRSIG RR(s) proving that the zone + does not contain a closer match for . If space does + not permit inclusion of the answer, NSEC and RRSIG RRs, the name + server MUST set the TC bit (see Section 3.1.1). + +3.1.3.4 Including NSEC RRs: Wildcard No Data Response + + This case is a combination of the previous cases. The zone does not + contain an exact match for , and while the zone does + contain RRsets which match via wildcard expansion, + none of those RRsets match STYPE. The name server MUST include the + following NSEC RRs in the Authority section, along with their + associated RRSIG RRs: + + o An NSEC RR proving that there are no RRsets matching STYPE at the + wildcard owner name which matched via wildcard + expansion; and + + o An NSEC RR proving that there are no RRsets in the zone which + + + +Arends, et al. Expires August 16, 2004 [Page 13] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + would have been a closer match for . + + In some cases a single NSEC RR may prove both of these points, in + which case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5 Finding The Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server needs to locate an NSEC RR + which proves that a particular SNAME does not exist. Locating such + an NSEC RR within an authoritative zone is relatively simple, at + least in concept. The following discussion assumes that the name + server is authoritative for the zone which would have held the + nonexistent SNAME. The algorithm below is written for clarity, not + efficiency. + + To find the NSEC which proves that name N does not exist in the zone + Z which would have held it, construct sequence S consisting of every + name in Z, sorted into canonical order + [I-D.ietf-dnsext-dnssec-records]. Find the name M which would have + immediately preceded N in S if N had existed. M is the owner name of + the NSEC RR which proves that N does not exist. + + The algorithm for finding the NSEC RR which proves that a given name + is not covered by any applicable wildcard is similar, but requires an + extra step. More precisely, the algorithm for finding the NSEC + proving that the applicable wildcard name does not exist is precisely + the same as the algorithm for finding the NSEC RR which proves that + any other name does not exist: the part that's missing is how to + determine the name of the nonexistent applicable wildcard. In + practice, this is easy, because the authoritative name server has + already checked for the presence of precisely this wildcard name as + part of step (1)(c) of the normal lookup algorithm described in + Section 4.3.2 of [RFC1034]. + +3.1.4 Including DS RRs In a Response + + When responding to a query which has the DO bit set to one, a + security-aware authoritative name server returning a referral + includes DNSSEC data along with the NS RRset. + + + +Arends, et al. Expires August 16, 2004 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. The name server MUST + place the NS RRset before the DS RRset and its associated RRSIG + RR(s). + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR which proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages, and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1 Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, since the name server for + the child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + + o the name server has received a query for the DS RRset at a zone + cut; and + + o the name server is authoritative for the child zone; and + + o the name server is not authoritative for the parent zone; and + + + + +Arends, et al. Expires August 16, 2004 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + o the name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all of the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5 Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation, and these RRs are treated as any other resource record + type. + + An authoritative name server is not required to verify that a zone is + properly signed before sending or accepting a zone transfer. + However, an authoritative name server MAY choose to reject the entire + zone transfer if the zone fails meets any of the signing requirements + described in Section 2. The primary objective of a zone transfer is + to ensure that all authoritative name servers have identical copies + of the zone. An authoritative name server which chooses to perform + its own zone validation MUST NOT selectively reject some RRs and + accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + of the zone in which the RRset is authoritative data: in the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut, and + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, since the NSEC RR in the child zone's apex will always + indicate the presence of the child zone's SOA RR while the parental + NSEC RR at the zone cut will never indicate the presence of an SOA + RR. As with any other authoritative RRs, NSEC RRs MUST be included + in zone transfers of the zone in which they are authoritative data: + the parental NSEC RR at a zone cut MUST be included zone transfers of + the parent zone, while the NSEC at the zone apex of the child zone + + + +Arends, et al. Expires August 16, 2004 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + MUST be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut, + and are authoritative in whichever zone contains the authoritative + RRset for which the RRSIG RR provides the signature. That is, the + RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, while the RRSIG for any RRset in + the child zone's apex will be authoritative in the child zone. As + with any other authoritative RRs, RRSIG RRs MUST be included in zone + transfers of the zone in which they are authoritative data. + +3.1.6 The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed to be used in communication between + security-aware resolvers and security-aware recursive name servers. + This bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + Since a security-aware name server does not perform signature + validation for authoritative data during query processing even when + the CD bit is set to zero, a security-aware name server SHOULD ignore + the setting of the CD bit when composing an authoritative response. + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation, but the name server + MUST NOT do so unless the name server obtained the authoritative zone + via secure means (such as a secure zone transfer mechanism), and MUST + NOT do so unless this behavior has been configured explicitly. + + A security-aware name server which supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2 Recursive Name Servers + + As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware + recursive name server is an entity which acts in both the + security-aware name server and security-aware resolver roles. This + section uses the terms "name server side" and "resolver side" to + refer to the code within a security-aware recursive name server which + implements the security-aware name server role and the code which + implements the security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching which would apply to any security-aware resolver. + + + +Arends, et al. Expires August 16, 2004 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +3.2.1 The DO bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response, but MUST + NOT strip any DNSSEC RRs that the initiating query explicitly + requested. + +3.2.2 The CD bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + 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 + or not it is required to verify the response data it returns to the + name server side. If the CD bit is set to one, it indicates that the + originating resolver is willing to perform whatever authentication + its local policy requires, thus the resolver side of the recursive + name server need not perform authentication on the RRsets in the + response. When the CD bit is set to one the recursive name server + SHOULD, if possible, return the requested data to the originating + resolver even if the recursive name server's local authentication + policy would reject the records in question. That is, by setting the + CD bit, the originating resolver has indicated that it takes + responsibility for performing its own authentication, and the + recursive name server should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query which matches an entry in the + resolver side's BAD cache, the name server side's response depends on + the sense of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + +3.2.3 The AD bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + + + +Arends, et al. Expires August 16, 2004 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + authentic, and SHOULD set the AD bit if and only if the resolver side + considers all RRsets in the Answer section and any relevant negative + response RRs in the Authority section to be authentic. The resolver + side MUST follow the procedure described in Section 5 to determine + whether the RRs in question are authentic. + +3.3 Example DNSSEC Responses + + See Appendix B for example response packets. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 19] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +4. Resolving + + This section describes the behavior of entities which include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1 EDNS Support + + A security-aware resolver MUST include an EDNS [RFC2671] OPT + pseudo-RR with the DO [RFC3225] bit set to one when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + advertise the supported message size using the "sender's UDP payload + size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST + handle fragmented UDP packets correctly regardless of whether any + such fragmented packets were received via IPv4 or IPv6. Please see + [RFC3226] for discussion of these requirements. + +4.2 Signature Verification Support + + 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. + + Editors' note: The rest of this section is expected to change once + the WG reaches closure on Q-23. + + A security-aware resolver MUST attempt to retrieve missing DS, + DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these + RRs in order to perform signature verification. + + + + +Arends, et al. Expires August 16, 2004 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + A security-aware resolver MUST attempt to retrieve a missing NSEC RR + which the resolver needs to authenticate a NODATA response. In + general it is not possible for a resolver to retrieve missing NSEC + RRs, since the resolver will have no way of knowing the owner name of + the missing NSEC RR, but in the specific case of a NODATA response, + the resolver may know the name of the missing NSEC RR, and in such + cases must therefore attempt to retrieve it. + + When attempting to retrieve missing NSEC RRs which reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name; if no NS RRset is present at that name, the + resolver then strips of the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + + Editors' note: This algorithm could easily be read as an + invitation to careless implementors to hammer the root zone + servers. Better wording would be welcome. + + +4.3 Determining Security Status of Data + + Editors' note: This section is waiting for resolution of Q-28. + + A security-aware resolver MUST be able to determine whether or not it + should expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between three + cases: + + 1. An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted security anchor to the + RRset. In this case, the RRset should be signed, and is subject + to signature validation as described above. + + 2. An RRset for which the resolver knows that it has no chain of + signed DNSKEY and DS RRs from any trusted starting point to the + RRset. This can occur when the target RRset lies in an unsigned + + + +Arends, et al. Expires August 16, 2004 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + 3. An RRset for which the resolver is not able to determine whether + or not the RRset should be signed, because the resolver is not + able to obtain the necessary DNSSEC RRs. This can occur when the + security-aware resolver is not able to contact security-aware + name servers for the relevant zones. + + +4.4 Preconfigured Public Keys + + A security-aware resolver MUST be capable of being preconfigured with + at least one trusted public key or DS RR, and SHOULD be capable of + being preconfigured with multiple trusted public keys or DS RRs. + Since a security-aware resolver will not be able to validate + signatures without such a preconfigured trusted key, the resolver + SHOULD have some reasonably robust mechanism for obtaining such keys + when it boots; examples of such a mechanism would be some form of + non-volatile storage (such as a disk drive) or some form of trusted + local network configuration mechanism. + +4.5 Response Caching + + Editors' note: RIPE "last call" workshop felt that the WG needs to + reexamine and discuss this section. + + A security-aware resolver SHOULD cache each response as a 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. In + most cases the appropriate cache index for the atomic entry will be + the triple , but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double . + +4.6 Handling of the CD and AD bits + + A security-aware resolver MAY set the CD bit in a query to one in + order to indicate that the resolver takes responsibility for + performing whatever authentication its local policy requires on the + RRsets in the response. See Section 3.2 for the effect this bit has + on the behavior of security-aware recursive name servers. + + A security-aware resolver MUST zero the AD bit when composing query + messages to protect against buggy name servers which blindly copy + header bits which they do not understand from the query message to + + + +Arends, et al. Expires August 16, 2004 [Page 22] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + the response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained using a secure channel or + the resolver was specifically configured to regard the message header + bits without using a secure channel. + +4.7 Rate Limiting + + A security-aware resolver SHOULD NOT cache data with invalid + signatures under normal circumstances. However, a security-aware + resolver SHOULD take steps to rate limit the number of identical + queries that it generates if signature validation of the responses + fails repeatedly. + + Conceptually, this is similar in some respects to negative caching + [RFC2308], but since the resolver has no way of obtaining an + appropriate caching TTL from received data in this case, the TTL will + have to be set by the implementation. This document refers to the + data retained as part of such a rate limiting mechanism as the "BAD + cache". + + A security-aware resolver MAY chose to retain RRsets for which + signature validation has failed in its BAD cache, but MUST NOT return + such RRsets from its BAD cache unless both of the following + conditions are met: + + o The resolver has recently generated enough queries identical to + this one that the resolver is suppressing queries for this ; and + + o The resolver is not required to validate the signatures of the + RRsets in question under the rules given in Section 4 of this + document. + + The intent of the above rule is to provide the raw data to clients + which are capable of performing their own signature verification + checks while protecting clients which depend on this resolver to + perform such checks. Several of the possible reasons why signature + validation might fail involve conditions which may not apply equally + to this resolver and the client which invoked it: for example, this + resolver's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security which this resolver does + not share. In such cases, "protecting" a client which is capable of + performing its own signature validation from ever seeing the "bad" + data does not help the client. + + + + + +Arends, et al. Expires August 16, 2004 [Page 23] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +4.8 Stub resolvers + + 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. + +4.8.1 Handling of the DO Bit + + A non-validating security-aware stub resolver MAY include the DNSSEC + RRs returned by a security-aware recursive name server as part of the + data that the stub resolver hands back to the application which + invoked it but is not required to do so. A non-validating stub + resolver that wishes to do this will need to set the DO bit in + receive DNSSEC RRs from the recursive name server. + + A validating security-aware stub resolver MUST set the DO bit, since + otherwise it will not receive the DNSSEC RRs it needs to perform + signature validation. + +4.8.2 Handling of the CD Bit + + A non-validating security-aware stub resolver SHOULD NOT set the CD + bit when sending queries unless requested by the application layer, + since by definition, a non-validating stub resolver depends on the + security-aware recursive name server to perform validation on its + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + since otherwise the security-aware recursive name server will answer + the query using the name server's local policy, which may prevent the + stub resolver from receiving data which would be acceptable to the + stub resolver's local policy. + +4.8.3 Handling of the AD Bit + + A non-validating security-aware stub resolver MAY chose to examine + the setting of the AD bit in response messages that it receives in + order to determine whether the security-aware recursive name server + which sent the response claims to have cryptographically verified the + data in the Answer and Authority sections of the response message. + Note, however, that the responses received by a security-aware stub + resolver are heavily dependent on the local policy of the + security-aware recursive name server, so as a practical matter there + may be little practical value to checking the status of the AD bit + except perhaps as a debugging aid. In any case, a security-aware + stub resolver MUST NOT place any reliance on signature validation + allegedly performed on its behalf except when the security-aware stub + resolver obtained the data in question from a trusted security-aware + + + +Arends, et al. Expires August 16, 2004 [Page 24] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + recursive name server via a secure channel. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, since, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 25] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +5. Authenticating DNS Responses + + In order to use DNSSEC RRs for authentication, a security-aware + resolver requires preconfigured knowledge of at least one + authenticated DNSKEY or DS RR. The process for obtaining and + authenticating this initial DNSKEY or DS RR is achieved via some + external mechanism. For example, a resolver could use some off-line + authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR + that identifies and authenticates a zone's DNSKEY RR. The remainder + of this section assumes that the resolver has somehow obtained an + initial set of authenticated DNSKEY RRs. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset using an initial key, + the resolver MUST: + + 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag + (DNSKEY RDATA bit 7) set to one. + + 2. Verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset using an + initial DNSKEY RR, delegations from that zone can be authenticated + using DS RRs. This allows a resolver to start from an initial key, + and use DS RRsets to proceed recursively down the DNS tree obtaining + other apex DNSKEY RRsets. If the resolver were preconfigured with a + root DNSKEY RR, and if every delegation had a DS RR associated with + it, then the resolver could obtain and validate any apex DNSKEY + RRset. The process of using DS RRs to authenticate referrals is + described in Section 5.2. + + Once the resolver has authenticated a zone's apex DNSKEY RRset, + Section 5.3 shows how the resolver can use DNSKEY RRs in the apex + DNSKEY RRset and RRSIG RRs from the zone to authenticate any other + RRsets in the zone. Section 5.4 shows how the resolver can use + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + that lacks the appropriate DNSSEC RRs, whether due to configuration + issues such as a security-oblivious recursive name server that + + + +Arends, et al. Expires August 16, 2004 [Page 26] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + accidentally interfere with DNSSEC RRs or due to a deliberate attack + in which an adversary forges a response, strips DNSSEC RRs from a + response, or modifies a query so that DNSSEC RRs appear not to be + requested. The absence of DNSSEC data in a response MUST NOT by + itself be taken as an indication that no authentication information + exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1 Special Considerations for Islands of Security + + Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed + zones for which it is not possible to construct an authentication + chain to the zone from its parent. Validating signatures within an + island of security requires the validator to have some other means of + obtaining an initial authenticated zone key for the island. If a + validator cannot obtain such a key, it will have to choose whether to + accept the unvalidated responses or not based on local policy. + + All the normal processes for validating responses apply to islands of + security. The only difference between normal validation and + validation within an island of security is in how the validator + obtains a starting point for the authentication chain. + +5.2 Authenticating Referrals + + Once the apex DNSKEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a DNSKEY RR in the child + zone's apex DNSKEY RRset, and contains a cryptographic digest of the + child zone's DNSKEY RR. A strong cryptographic digest algorithm + ensures that an adversary can not easily generate a DNSKEY RR that + matches the digest. Thus, authenticating the digest allows a + resolver to authenticate the matching DNSKEY RR. The resolver can + then use this child DNSKEY RR to authenticate the entire child apex + DNSKEY RRset. + + Given a DS RR for a delegation, the child zone's apex DNSKEY RRset + can be authenticated if all of the following hold: + + o The DS RR has been authenticated using some DNSKEY RR in the + parent's apex DNSKEY RRset (see Section 5.3); + + o The Algorithm and Key Tag in the DS RR match the Algorithm field + + + +Arends, et al. Expires August 16, 2004 [Page 27] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + and the key tag of a DNSKEY RR in the child zone's apex DNSKEY + RRset that, when hashed using the digest algorithm specified in + the DS RR's Digest Type field, results in a digest value that + matches the Digest field of the DS RR; and + + o The matching DNSKEY RR in the child zone has the Zone Flag bit set + to one, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the resolver authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the resolver can not authenticate RRsets in or below the + child zone. + + Note that, for a signed delegation, there are two NSEC RRs associated + with the delegated name. One NSEC RR resides in the parent zone, and + can be used to prove whether a DS RRset exists for the delegated + name. The second NSEC RR resides in the child zone, and identifies + which RRsets are present at the apex of the child zone. The parent + NSEC RR and child NSEC RR can always be distinguished, since the SOA + bit will be set in the child NSEC RR and clear in the parent NSEC RR. + A security-aware resolver MUST use the parent NSEC RR when attempting + to prove that a DS RRset does not exist. + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3 Authenticating an RRset Using an RRSIG RR + + A resolver can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The resolver first checks the RRSIG + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The resolver then constructs the + + + +Arends, et al. Expires August 16, 2004 [Page 28] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + canonical form of the signed data by appending the RRSIG RDATA + (excluding the Signature Field) with the canonical form of the + covered RRset. Finally, resolver uses the public key and signature + to authenticate the signed data. Section 5.3.1, Section 5.3.2, and + Section 5.3.3 describe each step in detail. + +5.3.1 Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + + o The RRSIG RR and the RRset MUST have the same owner name and the + same class; + + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset; + + o The RRSIG RR's Type Covered field MUST equal the RRset's type; + + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field; + + o The resolver's notion of the current time MUST be less than or + equal to the time listed in the RRSIG RR's Expiration field; + + o The resolver's notion of the current time MUST be greater than or + equal to the time listed in the RRSIG RR's Inception field; + + o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some DNSKEY RR in + the zone's apex DNSKEY RRset; + + o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY + RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) + set to one. + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the resolver can not predetermine which DNSKEY + RR to use to authenticate the signature, MUST try each matching + DNSKEY RR until the resolver has either validated the signature or + has run out of matching public keys to try. + + Note that this authentication process is only meaningful if the + resolver authenticates the DNSKEY RR before using it to validate + signatures. The matching DNSKEY RR is considered to be authentic if: + + o The apex DNSKEY RRset containing the DNSKEY RR is considered + authentic; or + + + +Arends, et al. Expires August 16, 2004 [Page 29] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + and the DNSKEY RR either matches an authenticated DS RR from the + parent zone or matches a DS RR or DNSKEY RR that the resolver has + been preconfigured to believe to be authentic. + + +5.3.2 Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + Section 5.3.1, the resolver needs to reconstruct the original signed + data. The original signed data includes RRSIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The resolver should use the following to + reconstruct the original signed data: + + signed_data = RRSIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signature field excluded and the Signer's Name + in canonical form. + + RR(i) = name | class | type | OrigTTL | RDATA length | RDATA + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the RRSIG Original TTL field + + All names in the RDATA field are in canonical form + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + + + +Arends, et al. Expires August 16, 2004 [Page 30] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + RRset. + + The canonical forms for names and RRsets are defined in + [I-D.ietf-dnsext-dnssec-records]. + + NSEC RRsets at a delegation boundary require special processing. + There are two distinct NSEC RRsets associated with a signed delegated + name. One NSEC RRset resides in the parent zone, and specifies which + RRset are present at the parent zone. The second NSEC RRset resides + at the child zone, and identifies which RRsets are present at the + apex in the child zone. The parent NSEC RRset and child NSEC RRset + can always be distinguished since only the child NSEC RRs will + specify an SOA RRset exists at the name. When reconstructing the + original NSEC RRset for the delegation from the parent zone, the NSEC + RRs MUST NOT be combined with NSEC RRs from the child zone, and when + reconstructing the original NSEC RRset for the apex of the child + zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent + zone. + + Note also that each of the two NSEC RRsets at a delegation point has + a corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + +5.3.3 Checking the Signature + + Once the resolver has validated the RRSIG RR as described in Section + 5.3.1 and reconstructed the original signed data as described in + Section 5.3.2, the resolver can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). + + + +Arends, et al. Expires August 16, 2004 [Page 31] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types, + and provides pointers to the documents that define each algorithm's + use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the resolver can only + determine which DNSKEY RR by trying each matching public key until + the resolver either succeeds in validating the signature or runs out + of keys to try. + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also needs to test these RRSIG + RRs, and determines how to resolve conflicts if these RRSIG RRs lead + to differing results. + + If the resolver accepts the RRset as authentic, the resolver MUST set + the TTL of the RRSIG RR and each RR in the authenticated RRset to a + value no greater than the minimum of: + + o The RRset's TTL as received in the response; + + o The RRSIG RR's TTL as received in the response; and + + o The value in the RRSIG RR's Original TTL field. + + +5.3.4 Authenticating A Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the resolver has verified the signature as described in Section + 5.3, the resolver must take additional steps to verify the + non-existence of an exact match or closer wildcard match for the + query. Section 5.4 discusses these steps. + + Note that the response received by the resolver should include all + NSEC RRs needed to authenticate the response (see Section 3.1.3). + +5.4 Authenticated Denial of Existence + + + + +Arends, et al. Expires August 16, 2004 [Page 32] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + A resolver can use authenticated NSEC RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NSEC RRs for signed zones in + their responses to security-aware resolvers. + + Security-aware resolvers MUST first authenticate NSEC RRsets + according to the standard RRset authentication rules described in + Section 5.3, then apply the NSEC RRsets as follows: + + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. + + o If the requested RR name would appear after an authenticated NSEC + RR's owner name and before the name listed in that NSEC RR's Next + Domain Name field according to the canonical DNS name order + defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with + the requested name exist 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 RRset exists that could + have been used to generate a positive response. + + To prove non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify non-existence of the requested RRset. As with all DNS + operations, however, the resolver MUST bound the work it puts into + answering any particular query. + + Since a verified NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a verifier MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + +5.5 Authentication Example + + Appendix C shows an example the authentication process. + + + + + +Arends, et al. Expires August 16, 2004 [Page 33] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +6. IANA Considerations + + [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA + considerations introduced by DNSSEC. The additional IANA + considerations discussed in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655] and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 34] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general + security considerations related to DNSSEC; see + [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the + DNSSEC resource record types. + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection which DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Section 3.2.2 and Section 4.8 for further discussion. + + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, + since recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will need to pay close attention to the + behavior of the applications which use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidently denying service to the clients it is + intended to support. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 35] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +8. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 36] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-09 (work in progress), + February 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-07 (work in progress), + February 2004. + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 37] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +Informative References + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [I-D.ietf-dnsext-wcard-clarify] + Halley, B. and E. Lewis, "Clarifying the Role of Wild Card + Domains in the Domain Name System", + draft-ietf-dnsext-wcard-clarify-02 (work in progress), + September 2003. + + +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 + + + + + + +Arends, et al. Expires August 16, 2004 [Page 38] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 39] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz + +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj + s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY + eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH + FTVyQbVkcaxQ6U2FbZtMbfo//go= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18 + 7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe + IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+ + M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q + 7wxkDWyzgasGiMNIKgYrm9vXz04= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT + vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX + TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g + Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 + 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) + 3600 DNSKEY 256 3 5 ( + AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH + UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV + fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv + BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO + + + +Arends, et al. Expires August 16, 2004 [Page 40] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q== + ) + 3600 DNSKEY 257 3 5 ( + AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U + Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv + klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE + 2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT + nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU + pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5 + YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc + tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG + PjJstq6fvRq8kX7TPJcljUmDFKM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( + 20031216201552 60717 example. + EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/ + C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK + L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY + J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34 + Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 48327 5 1 ( + DFEB5E00E71A4DED5CABBBD7F15F24871983 + CAB7 ) + 3600 RRSIG DS 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ + hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb + rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c + ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC + 0yfe2uolEkeegjesDZuF+fC61Eg= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb + RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1 + 3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O + ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf + YgfAHJEJJj7K88QbKEK4/Je1hyk= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + + + +Arends, et al. Expires August 16, 2004 [Page 41] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 + jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c + Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk + OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A + sWifTxvcG5hv+A6TOd0O2xJYRik= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + 4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C + hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2 + KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2 + Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92 + xo9NLoltg0GuwggZM240pRoTwO8= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 + 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ + G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI + A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI + zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE + ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y + ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU + 4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR + ovChG5Ih3TOa8Qnch4IJQVfSFNU= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs + VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW + VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN + k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX + GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 + CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs + RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf + +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa + + + +Arends, et al. Expires August 16, 2004 [Page 42] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ + sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 + eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA + s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj + I2A5W86mMEbSgEF/pZHX/wi5FJI= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL + xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK + HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht + sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG + wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb + IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b + f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J + aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl + yCup5bk/Dr47eU2/6+lqrBTOV8Q= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg + OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns + Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA + n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK + 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr + f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 + 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK + /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW + ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040115201552 ( + 20031216201552 41681 example. + g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW + ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m + 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY + MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv + + + +Arends, et al. Expires August 16, 2004 [Page 43] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + btznHMFDIbtuw/tAX7xXH2pDDHY= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040115201552 ( + 20031216201552 41681 example. + zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia + CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA + EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA + aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT + 3lMXiX4KNWUhB87q/pT/5z+xrqY= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040115201552 ( + 20031216201552 41681 example. + slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD + v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE + unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK + Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk + Iykd5UmaTO5j4LlRnAvF8Z1m9/k= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040115201552 ( + 20031216201552 41681 example. + sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 + VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj + Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq + AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J + viOQHZ6I4xoZQP5G7r98/PhlrLM= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap + tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq + iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS + KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G + 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw + p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA + gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/ + pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp + EDXT07qFXtGntvBSpF9uQbEub6Y= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 + dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD + mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg + CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z + + + +Arends, et al. Expires August 16, 2004 [Page 44] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + D4ZubIon0XGe9fIjLnmb3pX/FUk= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn + uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE + NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a + 1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187 + sSNF3PAC0HPadh7SdHmXlFQtQ44= ) + + The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA + Flags indicate that each of these DNSKEY RRs is a zone key. One of + these DNSKEY RRs also has the SEP flag set and has been used to sign + the apex DNSKEY RRset; this is the key which should be hashed to + generate a DS record to be inserted into the parent zone. The other + DNSKEY is used to sign all the other RRsets in the zone. + + The zone includes a wildcard entry "*.w.example". Note that the name + "*.w.example" is used in constructing NSEC chains, and that the RRSIG + covering the "*.w.example" MX RRset has a label count of 2. + + The zone also includes two delegations. The delegation to + "b.example" includes an NS RRset, glue address records, and an NSEC + RR; note that only the NSEC RRset is signed. The delegation to + "a.example" provides a DS RR; note that only the NSEC and DS RRsets + are signed. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 45] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1 Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 ( + 20031216201552 41681 example. + g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW + ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m + 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY + MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv + btznHMFDIbtuw/tAX7xXH2pDDHY= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz + +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj + s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY + eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH + FTVyQbVkcaxQ6U2FbZtMbfo//go= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap + tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq + iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS + KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G + 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 + + + +Arends, et al. Expires August 16, 2004 [Page 46] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD + mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg + CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z + D4ZubIon0XGe9fIjLnmb3pX/FUk= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 + CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs + RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf + +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa + WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL + xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK + HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht + sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG + wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) + + +B.2 Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + + + +Arends, et al. Expires August 16, 2004 [Page 47] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs + VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW + VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN + k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX + GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT + vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX + TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g + Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 + 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) + + ;; Additional + ;; (empty) + + +B.3 No Data Error + + A "NODATA" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + + + +Arends, et al. Expires August 16, 2004 [Page 48] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ + sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 + eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA + s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj + I2A5W86mMEbSgEF/pZHX/wi5FJI= ) + + ;; Additional + ;; (empty) + + +B.4 Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 48327 5 1 ( + DFEB5E00E71A4DED5CABBBD7F15F24871983 + CAB7 ) + a.example. 3600 RRSIG DS 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ + hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb + rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c + ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC + 0yfe2uolEkeegjesDZuF+fC61Eg= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + + + + +Arends, et al. Expires August 16, 2004 [Page 49] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +B.5 Referral to Unsigned Zone + + Referral to an unsigned zone. The NSEC RR proves that no DS RR for + this delegation exists in the parent zone. + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs + VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW + VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN + k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX + GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + + +B.6 Wildcard Expansion + + A successful query which was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg + OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns + + + +Arends, et al. Expires August 16, 2004 [Page 50] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA + n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK + 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz + +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj + s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY + eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH + FTVyQbVkcaxQ6U2FbZtMbfo//go= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( + 20031216201552 41681 example. + sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 + VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj + Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq + AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J + viOQHZ6I4xoZQP5G7r98/PhlrLM= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 + jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c + Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk + OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A + sWifTxvcG5hv+A6TOd0O2xJYRik= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 + 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ + G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI + A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI + zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) + + +B.7 Wildcard No Data Error + + A "NODATA" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + + + +Arends, et al. Expires August 16, 2004 [Page 51] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( + 20031216201552 41681 example. + sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 + VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj + Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq + AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J + viOQHZ6I4xoZQP5G7r98/PhlrLM= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr + f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 + 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK + /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW + ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) + + ;; Additional + ;; (empty) + + +B.8 DS Child Zone No Data Error + + A "NODATA" response for a QTYPE=DS query which was mistakenly sent to + a name server for the child zone. + + + +Arends, et al. Expires August 16, 2004 [Page 52] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT + vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX + TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g + Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 + 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) + + ;; Additional + ;; (empty) + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 53] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1 Authenticating An Answer + + The query in section Appendix B.1 returned an MX RRset for + "x.w.example.com". The corresponding RRSIG indicates the MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 41681. + The resolver needs the corresponding DNSKEY RR in order to + authenticate this answer. The discussion below describes how a + resolver might obtain this DNSKEY RR. + + The RRSIG indicates the original TTL of the MX RRset was 3600 and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates the answer was + not the result of wildcard expansion. The "x.w.example.com" MX RRset + is placed in canonical form and, assuming the current time falls + between the signature inception and expiration dates, the signature + is authenticated. + +C.1.1 Authenticating the example DNSKEY RR + + This example shows the logical authentication process that starts + from the a preconfigured root DNSKEY (or DS RR) and moves down the + tree to authenticate the desired "example" DNSKEY RR. Note the + logical order is presented for clarity and an implementation may + choose to construct the authentication as referrals are received or + may choose to construct the authentication chain only after all + RRsets have been obtained, or in any other combination it sees fit. + The example here demonstrates only the logical process and does not + dictate any implementation rules. + + We assume the resolver starts with an preconfigured DNSKEY RR for the + root zone (or a preconfigured DS RR for the root zone). The resolver + checks this preconfigured DNSKEY RR is present in the root DNSKEY + RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset), + this DNSKEY RR has signed the root DNSKEY RRset and the signature + lifetime is valid. If all these conditions are met, all keys in the + DNSKEY RRset are considered authenticated. The resolver then uses + one (or more) of the root DNSKEY RRs to authenticate the "example" DS + RRset. Note the resolver may need to query the root zone to obtain + the root DNSKEY RRset and/or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + + + +Arends, et al. Expires August 16, 2004 [Page 54] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + matching "example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the "example" + DNSKEY RRset are considered authenticated. + + Finally the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This + DNSKEY is used to authenticated the RRSIG included in the response. + If multiple "example" DNSKEY RRs have algorithm 5 and key tag of + 41681, then each DNSKEY RR is tried and the answer is authenticated + if either DNSKEY RR validates the signature as described above. + +C.2 Name Error + + The query in section Appendix B.2 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3 No Data Error + + The query in section Appendix B.3 returned an NSEC RR that proves the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4 Referral to Signed Zone + + The query in section Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "a.example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the + "a.example" DNSKEY RRset are considered authenticated. + +C.5 Referral to Unsigned Zone + + The query in section Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + "example" to "b.example" and the NSEC RR is authenticated in a manner + + + +Arends, et al. Expires August 16, 2004 [Page 55] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + identical to that of the MX RRset discussed above. + +C.6 Wildcard Expansion + + The query in section Appendix B.6 returned an answer that was + produced as a result of wildcard expansion. The RRset expanded as + the similar to The corresponding RRSIG indicates the MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 41681. + The RRSIG indicates the original TTL of the MX RRset was 3600 and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 2 indicates the answer the + result of wildcard expansion since the "a.z.w.example" name contains + 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", + the MX RRset is placed in canonical form and, assuming the current + time falls between the signature inception and expiration dates, the + signature is authenticated. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7 Wildcard No Data Error + + The query in section Appendix B.7 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8 DS Child Zone No Data Error + + The query in section Appendix B.8 returned NSEC RRs that shows the + requested was answered by a child server ("example" server). The + NSEC RR indicates the presence of an SOA RR, showing the answer is + from the child . Queries for the "example" DS RRset should be sent + to the parent servers ("root" servers). + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 56] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires August 16, 2004 [Page 57] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + + 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 August 16, 2004 [Page 58] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt new file mode 100644 index 0000000000..cfd3567f0a --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt @@ -0,0 +1,2073 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: August 16, 2004 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + February 16, 2004 + + + Resource Records for the DNS Security Extensions + draft-ietf-dnsext-dnssec-records-07 + +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 August 16, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents that describes the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + public key (DNSKEY), delegation signer (DS), resource record digital + + + +Arends, et al. Expires August 16, 2004 [Page 1] + +Internet-Draft DNSSEC Resource Records February 2004 + + + signature (RRSIG), and authenticated denial of existence (NSEC) + resource records. The purpose and format of each resource record is + described in detail, and an example of each resource record is given. + + 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. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 6 + 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . . . . 7 + 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7 + 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9 + 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . . 9 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 12 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 + 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13 + 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15 + 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 + 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . . . . 16 + 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 17 + 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 17 + 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 19 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 19 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 20 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 20 + + + +Arends, et al. Expires August 16, 2004 [Page 2] + +Internet-Draft DNSSEC Resource Records February 2004 + + + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20 + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 20 + 5.2 Processing of DS RRs When Validating Responses . . . . . . . 20 + 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 21 + 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 21 + 6. Canonical Form and Order of Resource Records . . . . . . . . 22 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 22 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 22 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 23 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 26 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 + Normative References . . . . . . . . . . . . . . . . . . . . 28 + Informative References . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 32 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 32 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 32 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35 + Intellectual Property and Copyright Statements . . . . . . . 36 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 3] + +Internet-Draft DNSSEC Resource Records February 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the + purpose of each resource record (RR), the RR's RDATA format, and its + presentation format (ASCII representation). + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs + that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 + [RFC2308]. + + 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 and data integrity to the Domain Name + System (DNS). An introduction to DNSSEC and definitions of common + terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description + of DNS protocol modifications can be found in + [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC + resource records. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3 Editors' Notes + +1.3.1 Open Technical Issues + + The cryptographic algorithm types (Appendix A) requires input from + the working group. The DSA algorithm was moved to OPTIONAL. This + had strong consensus in workshops and various discussions and a + separate Internet-Draft solely to move DSA from MANDATORY to OPTIONAL + seemed excessive. This draft solicits input on that proposed change. + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + + +Arends, et al. Expires August 16, 2004 [Page 4] + +Internet-Draft DNSSEC Resource Records February 2004 + + + 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 August 16, 2004 [Page 5] + +Internet-Draft DNSSEC Resource Records February 2004 + + +2. The DNSKEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in DNSKEY + resource records and are used in the DNSSEC authentication process + described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its + authoritative RRsets using a private key and stores the corresponding + public key in a DNSKEY RR. A resolver can then use the public key to + authenticate signatures covering the RRsets in the zone. + + The DNSKEY RR is not intended as a record for storing arbitrary + public keys, and MUST NOT be used to store certificates or public + keys that do not directly relate to the DNS infrastructure. + + The Type value for the DNSKEY RR type is 48. + + The DNSKEY RR is class independent. + + The DNSKEY RR has no special TTL requirements. + +2.1 DNSKEY RDATA Wire Format + + The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 + octet Protocol Field, a 1 octet Algorithm Field, and the Public Key + Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner + name MUST be the name of a zone. If bit 7 has value 0, then the + DNSKEY record holds some other type of DNS public key, such as a + public key used by TKEY and MUST NOT be used to verify RRSIGs that + cover RRsets. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1, + + + +Arends, et al. Expires August 16, 2004 [Page 6] + +Internet-Draft DNSSEC Resource Records February 2004 + + + then the DNSKEY record holds a key intended for use as a secure entry + point. This flag is only intended to be to a hint to zone signing or + debugging software as to the intended use of this DNSKEY record; + security-aware resolvers MUST NOT alter their behavior during the + signature validation process in any way based on the setting of this + bit. + + Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon + creation of the DNSKEY RR, and MUST be ignored upon reception. + +2.1.2 The Protocol Field + + The Protocol Field MUST have value 3 and MUST be treated as invalid + during signature verification if found to be some value other than 3. + +2.1.3 The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4 The Public Key Field + + The Public Key Field holds the public key material. The format + depends on the algorithm of the key being stored and are described in + separate documents. + +2.1.5 Notes on DNSKEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with early versions of the KEY record. + +2.2 The DNSKEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field MUST be represented as an unsigned decimal integer + with a value of 0, 256, or 257. + + The Protocol Field MUST be represented as an unsigned decimal integer + with a value of 3. + + The Algorithm field MUST be represented either as an unsigned + decimal integer or as an algorithm mnemonic as specified in Appendix + A.1. + + The Public Key field MUST be represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + + + +Arends, et al. Expires August 16, 2004 [Page 7] + +Internet-Draft DNSSEC Resource Records February 2004 + + + definition of Base64 encoding, see [RFC1521] Section 5.2. + +2.3 DNSKEY RR Example + + The following DNSKEY RR stores a DNS zone key for example.com. + + example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 + Cbl+BBZH4b/0PY1kxkmvHjcZc8no + kfzj31GajIQKY+5CptLr3buXA10h + WqTkF7H6RfoRqXQeogmMHfpftf6z + Mv1LyBUgia7za6ZEzOJBOztyvhjL + 742iU/TpPSEDhm2SNKLijfUppn1U + aNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in + the Flags field has value 1. Value 3 is the fixed Protocol value. + Value 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [RFC3110]. The remaining + text is a Base64 encoding of the public key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 8] + +Internet-Draft DNSSEC Resource Records February 2004 + + +3. The RRSIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Digital signatures are stored in + RRSIG resource records and are used in the DNSSEC authentication + process described in [I-D.ietf-dnsext-dnssec-protocol]. A + security-aware resolver can use these RRSIG RRs to authenticate + RRsets from the zone. The RRSIG RR MUST only be used to carry + verification material (digital signatures) used to secure DNS + operations. + + An RRSIG record contains the signature for an RRset with a particular + name, class, and type. The RRSIG RR specifies a validity interval + for the signature and uses the Algorithm, the Signer's Name, and the + Key Tag to identify the DNSKEY RR containing the public key that a + resolver can use to verify the signature. + + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034] that stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a secure + zone. + + The Type value for the RRSIG RR type is 46. + + The RRSIG RR is class independent. + + An RRSIG RR MUST have the same class as the RRset it covers. + + The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset + it covers. This is an exception to the [RFC2181] rules for TTL + values of individual RRs within a RRset: individual RRSIG with the + same owner name will have different TTL values if the RRsets that + they cover have different TTL values. + +3.1 RRSIG RDATA Wire Format + + The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a + 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original + TTL field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Arends, et al. Expires August 16, 2004 [Page 9] + +Internet-Draft DNSSEC Resource Records February 2004 + + + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 The Type Covered Field + + The Type Covered field identifies the type of the RRset which is + covered by this RRSIG record. + +3.1.2 The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3 The Labels Field + + The Labels field specifies the number of labels in the original RRSIG + RR owner name. The significance of this field is that from it a + verifier can determine if the answer was synthesized from a wildcard. + If so, it can be used to determine what owner name was used in + generating the signature. + + To validate a signature, the validator needs the original owner name + that was used to create the signature. If the original owner name + contains a wildcard label ("*"), the owner name may have been + expanded by the server during the response process, in which case the + validator will need to reconstruct the original owner name in order + to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] + describes how to use the Labels field to reconstruct the original + owner name. + + The value of the Labels field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + + + +Arends, et al. Expires August 16, 2004 [Page 10] + +Internet-Draft DNSSEC Resource Records February 2004 + + + present). The value of the Labels field MUST be less than or equal + to the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Labels field value of 3, and + "*.example.com." has a Labels field value of 2. Root (".") has a + Labels field value of 0. + + Although the wildcard label is not included in the count stored in + the Labels field of the RRSIG RR, the wildcard label is part of the + RRset's owner name when generating or verifying the signature. + +3.1.4 Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a resolver requires the original TTL. + [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original + TTL field value to reconstruct the original TTL. + +3.1.5 Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The RRSIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + Signature Expiration and Inception field values are in POSIX.1 time + format: a 32-bit unsigned number of seconds elapsed since 1 January + 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The + longest interval which can be expressed by this format without + wrapping is approximately 136 years. An RRSIG RR can have an + Expiration field value which is numerically smaller than the + Inception field value if the expiration field value is near the + 32-bit wrap-around point or if the signature is long lived. Because + of this, all comparisons involving these fields MUST use "Serial + number arithmetic" as defined in [RFC1982]. As a direct consequence, + the values contained in these fields cannot refer to dates more than + 68 years in either the past or the future. + +3.1.6 The Key Tag Field + + The Key Tag field contains the key tag value of the DNSKEY RR that + validates this signature. Appendix B explains how to calculate Key + Tag values. + + + + + +Arends, et al. Expires August 16, 2004 [Page 11] + +Internet-Draft DNSSEC Resource Records February 2004 + + +3.1.7 The Signer's Name Field + + The Signer's Name field value identifies the owner name of the DNSKEY + RR which a security-aware resolver should use to validate this + signature. The Signer's Name field MUST contain the name of the zone + of the covered RRset. A sender MUST NOT use DNS name compression on + the Signer's Name field when transmitting a RRSIG RR. A receiver + which receives an RRSIG RR containing a compressed Signer's Name + field SHOULD decompress the field value. + +3.1.8 The Signature Field + + The Signature field contains the cryptographic signature which covers + the RRSIG RDATA (excluding the Signature field) and the RRset + specified by the RRSIG owner name, RRSIG class, and RRSIG Type + Covered field. The format of this field depends on the algorithm in + use and these formats are described in separate companion documents. + +3.1.8.1 Signature Calculation + + A signature covers the RRSIG RDATA (excluding the Signature Field) + and covers the data RRset specified by the RRSIG owner name, RRSIG + class, and RRSIG Type Covered fields. The RRset is in canonical form + (see Section 6) and the set RR(1),...RR(n) is signed as follows: + + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | class | type | TTL | RDATA length | RDATA; + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the RRSIG RR; + + Each RR MUST have the same class as the RRSIG RR; + + Each RR in the RRset MUST have the RR type listed in the + RRSIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the + RRSIG Original TTL Field; + + + +Arends, et al. Expires August 16, 2004 [Page 12] + +Internet-Draft DNSSEC Resource Records February 2004 + + + Any DNS names in the RDATA field of each RR MUST be in + canonical form; and + + The RRset MUST be sorted in canonical order. + + +3.2 The RRSIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field value MUST be represented either as an + unsigned decimal integer or as the mnemonic for the covered RR type. + + The Algorithm field value MUST be represented either as an unsigned + decimal integer or as an algorithm mnemonic as specified in Appendix + A.1. + + The Labels field value MUST be represented as an unsigned decimal + integer. + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Expiration Time and Inception Time field values MUST be + represented in the form YYYYMMDDHHmmSS in UTC, where: + + YYYY is the year (0000-9999, but see Section 3.1.5); + + MM is the month number (01-12); + + DD is the day of the month (01-31); + + HH is the hour in 24 hours notation (00-23); + + mm is the minute (00-59); + + SS is the second (00-59). + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Signer's Name field value MUST be represented as a domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding see [RFC1521] Section 5.2. + +3.3 RRSIG RR Example + + + + +Arends, et al. Expires August 16, 2004 [Page 13] + +Internet-Draft DNSSEC Resource Records February 2004 + + + The following an RRSIG RR stores the signature for the A RRset of + host.example.com: + + host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + The first four fields specify the owner name, TTL, Class, and RR type + (RRSIG). The "A" represents the Type Covered field. The value 5 + identifies the algorithm used (RSA/SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the RRSIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of RRSIG RR owner name, class, and Type Covered + indicate that this RRSIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate this signature can be + authenticated using an example.com zone DNSKEY RR whose algorithm is + 5 and key tag is 2642. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 14] + +Internet-Draft DNSSEC Resource Records February 2004 + + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the owner name of + the next authoritative RRset in the canonical ordering of the zone, + and the set of RR types present at the NSEC RR's owner name. The + complete set of NSEC RRs in a zone both indicate which authoritative + RRsets exist in a zone and also form a chain of authoritative owner + names in the zone. This information is used to provide authenticated + denial of existence for DNS data, as described in + [I-D.ietf-dnsext-dnssec-protocol]. + + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034] that + stated that if a CNAME is present for a name, it is the only type + allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist + for the same name as a CNAME resource record in a secure zone. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirt of negative caching [RFC2308]. + +4.1 NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The Next Domain Name field contains the owner name of the next + authoritative owner name in the canonical ordering of the zone; see + Section 6.1 for an explanation of canonical ordering. The value of + the Next Domain Name field in the last NSEC record in the zone is the + name of the zone apex (the owner name of the zone's SOA RR). + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. A receiver which receives an + + + +Arends, et al. Expires August 16, 2004 [Page 15] + +Internet-Draft DNSSEC Resource Records February 2004 + + + NSEC RR containing a compressed Next Domain Name field SHOULD + decompress the field value. + + Owner names of RRsets not authoritative for the given zone (such as + glue records) MUST NOT be listed in the Next Domain Name unless at + least one authoritative RRset exists at the same owner name. + +4.1.2 The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC RR's owner name. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that has + at least one active RR type is encoded using a single octet window + number (from 0 to 255), a single octet bitmap length (from 1 to 32) + indicating the number of octets used for the window block's bitmap, + and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC RR's owner name. + + Since bit 0 in window block 0 refers to the non-existent RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing pseudo-types MUST be set to 0, since they do not + appear in zone data. If encountered, they MUST be ignored upon + reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + + + +Arends, et al. Expires August 16, 2004 [Page 16] + +Internet-Draft DNSSEC Resource Records February 2004 + + + interpreted as zero octets. + + A zone MUST NOT generate an NSEC RR for any domain name that only + holds glue records. + +4.1.3 Inclusion of Wildcard Names in NSEC RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for purposes of generating NSEC RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards + on authenticated denial of existence. + +4.2 The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + as described in [RFC3597] (section 5) MUST be used. + +4.3 NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, + and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and + TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + + + +Arends, et al. Expires August 16, 2004 [Page 17] + +Internet-Draft DNSSEC Resource Records February 2004 + + + 0x00 0x00 0x00 0x00 0x20 + + Assuming that the resolver can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or could + be used to prove there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + [I-D.ietf-dnsext-dnssec-protocol]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 18] + +Internet-Draft DNSSEC Resource Records February 2004 + + +5. The DS Resource Record + + The DS Resource Record refers to a DNSKEY RR and is used in the DNS + DNSKEY authentication process. A DS RR refers to a DNSKEY RR by + storing the key tag, algorithm number, and a digest of the DNSKEY RR. + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The DS RR and its corresponding DNSKEY RR have the same owner name, + but they are stored in different locations. The DS RR appears only + on the upper (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). The corresponding DNSKEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing, but introduces special response + processing requirements for the DS RR; these are described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + The DS RR has no special TTL requirements. + +5.1 DS RDATA Wire Format + + The RDATA for a DS RR consists of a 2 octet Key Tag field, a one + octet Algorithm field, a one octet Digest Type field, and a Digest + field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 19] + +Internet-Draft DNSSEC Resource Records February 2004 + + +5.1.1 The Key Tag Field + + The Key Tag field lists the key tag of the DNSKEY RR referred to by + the DS record. + + The Key Tag used by the DS RR is identical to the Key Tag used by + RRSIG RRs. Appendix B describes how to compute a Key Tag. + +5.1.2 The Algorithm Field + + The Algorithm field lists the algorithm number of the DNSKEY RR + referred to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm + number types. + +5.1.3 The Digest Type Field + + The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY + RR. The Digest Type field identifies the algorithm used to construct + the digest. Appendix A.2 lists the possible digest algorithm types. + +5.1.4 The Digest Field + + The DS record refers to a DNSKEY RR by including a digest of that + DNSKEY RR. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, + and then applying the digest algorithm. + + digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); + + "|" denotes concatenation + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. + + + The size of the digest may vary depending on the digest algorithm and + DNSKEY RR size. As of the time of writing, the only defined digest + algorithm is SHA-1, which produces a 20 octet digest. + +5.2 Processing of DS RRs When Validating Responses + + The DS RR links the authentication chain across zone boundaries, so + the DS RR requires extra care in processing. The DNSKEY RR referred + to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST + + + +Arends, et al. Expires August 16, 2004 [Page 20] + +Internet-Draft DNSSEC Resource Records February 2004 + + + have Flags bit 7 set to value 1. If the key tag does not indicate a + DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT be + used in the validation process. + +5.3 The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field MUST be represented as an unsigned decimal + integer. + + The Digest MUST be represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.4 DS RR Example + + The following example shows a DNSKEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm + used by this "dskey.example.com." DNSKEY RR. The value 1 is the + algorithm used to construct the digest, and the rest of the RDATA + text is the digest in hexadecimal. + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 21] + +Internet-Draft DNSSEC Resource Records February 2004 + + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NSEC name chain. A canonical RR form and ordering + within an RRset are required to construct and verify RRSIG RRs. + +6.1 Canonical DNS Name Order + + For purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and upper case + US-ASCII letters are treated as if they were lower case US-ASCII + letters. + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + names ending "z.example". The names within each level are sorted in + the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + + +6.2 Canonical RR Form + + For purposes of DNS security, the canonical form of an RR is the wire + format of the RR where: + + 1. Every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + + 2. All uppercase US-ASCII letters in the owner name of the RR are + + + +Arends, et al. Expires August 16, 2004 [Page 22] + +Internet-Draft DNSSEC Resource Records February 2004 + + + replaced by the corresponding lowercase US-ASCII letters; + + 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in + the DNS names contained within the RDATA are replaced by the + corresponding lowercase US-ASCII letters; + + 4. If the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + + 5. The RR's TTL is set to its original value as it appears in the + originating authoritative zone or the Original TTL field of the + covering RRSIG RR. + + +6.3 Canonical RR Ordering Within An RRset + + For purposes of DNS security, RRs with the same owner name, class, + and type are sorted by treating the RDATA portion of the canonical + form of each RR as a left-justified unsigned octet sequence where the + absence of an octet sorts before a zero octet. + + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs during + RRset canonicalization, the implementation MUST treat this as a + protocol error. If the implementation chooses to handle this + protocol error in the spirit of the robustness principle (being + liberal in what it accepts), the implementation MUST remove all but + one of the duplicate RR(s) for purposes of calculating the canonical + form of the RRset. + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 23] + +Internet-Draft DNSSEC Resource Records February 2004 + + +7. IANA Considerations + + This document introduces no new IANA considerations, because all of + the protocol parameters used in this document have already been + assigned by previous specifications. However, since the evolution of + DNSSEC has been long and somewhat convoluted, this section attempts + to describe the current state of the IANA registries and other + protocol parameters which are (or once were) related to DNSSEC. + + Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA + considerations. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS + Resource Record Type 43 to DS. + [I-D.ietf-dnsext-dnssec-2535typecode-change] assigned types 46, + 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. + [I-D.ietf-dnsext-dnssec-2535typecode-change] also marked type 30 + (NXT) as Obsolete, and restricted use of types 24 (SIG) and 25 + (KEY) to the "SIG(0)" transaction security protocol described in + [RFC2931] and the transaction KEY Resource Record described in + [RFC2930]. + + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers, and assigned + values 1-4 and 252-255. [RFC3110] assigned value 5. + [I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry + to include flags for each entry regarding its use with the DNS + security extensions. Each algorithm entry could refer to an + algorithm that can be used for zone signing, transaction security + (see [RFC2931]) or both. Values 6-251 are available for assignment + by IETF standards action. See Appendix A for a full listing of the + DNS Security Algorithm Numbers entries at the time of writing and + their status of use in DNSSEC. + + [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and + assigned value 0 to reserved and value 1 to SHA-1. + + KEY Protocol Values: [RFC2535] created an IANA Registry for KEY + Protocol Values, but [RFC3445] re-assigned all assigned values + other than 3 to reserved and closed this IANA registry. The + registry remains closed, and all KEY and DNSKEY records are + required to have Protocol Octet value of 3. + + Flag bits in the KEY and DNSKEY RRs: + [I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains an assignment for bit 7 (the ZONE bit) + + + +Arends, et al. Expires August 16, 2004 [Page 24] + +Internet-Draft DNSSEC Resource Records February 2004 + + + and a reservation for bit 15 for the Secure Entry Point flag (SEP + bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14 + are available for assignment by IETF Standards Action. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 25] + +Internet-Draft DNSSEC Resource Records February 2004 + + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions, and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] + and [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations related to the use of these records. + + The DS record points to a DNSKEY RR using a cryptographic digest, the + key algorithm type and a key tag. The DS record is intended to + identify an existing DNSKEY RR, but it is theoretically possible for + an attacker to generate a DNSKEY that matches all the DS fields. The + probability of constructing such a matching DNSKEY depends on the + type of digest algorithm in use. The only currently defined digest + algorithm is SHA-1, and the working group believes that constructing + a public key which would match the algorithm, key tag, and SHA-1 + digest given in a DS record would be a sufficiently difficult problem + that such an attack is not a serious threat at this time. + + The key tag is used to help select DNSKEY resource records + efficiently, but it does not uniquely identify a single DNSKEY + resource record. It is possible for two distinct DNSKEY RRs to have + the same owner name, the same algorithm type, and the same key tag. + An implementation which used only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 26] + +Internet-Draft DNSSEC Resource Records February 2004 + + +9. Acknowledgments + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 27] + +Internet-Draft DNSSEC Resource Records February 2004 + + +Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet + Mail Extensions) Part One: Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1521, September 1993. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [I-D.ietf-dnsext-dnssec-intro] + + + +Arends, et al. Expires August 16, 2004 [Page 28] + +Internet-Draft DNSSEC Resource Records February 2004 + + + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-09 (work in progress), + February 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in + progress), February 2004. + + [I-D.ietf-dnsext-keyrr-key-signing-flag] + Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", + draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in + progress), December 2003. + + [I-D.ietf-dnsext-dnssec-2535typecode-change] + Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 + (work in progress), December 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 29] + +Internet-Draft DNSSEC Resource Records February 2004 + + +Informative References + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + + + + +Arends, et al. Expires August 16, 2004 [Page 30] + +Internet-Draft DNSSEC Resource Records February 2004 + + + 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 August 16, 2004 [Page 31] + +Internet-Draft DNSSEC Resource Records February 2004 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS + resource records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1 DNSSEC Algorithm Types + + The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify + the security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. + + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs as described in [RFC2931] + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman [DH] n RFC 2539 - + 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. + +A.1.1 Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with a wire encoded + + + +Arends, et al. Expires August 16, 2004 [Page 32] + +Internet-Draft DNSSEC Resource Records February 2004 + + + domain name, which MUST NOT be compressed. The domain name indicates + the private algorithm to use and the remainder of the public key area + is determined by that algorithm. Entities should only use domain + names they control to designate their private algorithms. + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with an unsigned + length byte followed by a BER encoded Object Identifier (ISO OID) of + that length. The OID indicates the private algorithm in use and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2 DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 33] + +Internet-Draft DNSSEC Resource Records February 2004 + + +Appendix B. Key Tag Calculation + + The Key Tag field in the RRSIG and DS resource record types provides + a mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a DNSKEY record. Both the RRSIG and DS resource records + have corresponding DNSKEY records. The Key Tag field in the RRSIG + and DS records can be used to help select the corresponding DNSKEY RR + efficiently when more than one candidate DNSKEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct DNSKEY RRs + to have the same owner name, the same algorithm, and the same key + tag. The key tag is used to limit the possible candidate keys, but it + does not uniquely identify a DNSKEY record. Implementations MUST NOT + assume that the key tag uniquely identifies a DNSKEY RR. + + The key tag is the same for all DNSKEY algorithm types except + algorithm 1 (please see Appendix B.1 for the definition of the key + tag for algorithm 1). The key tag algorithm is the sum of the wire + format of the DNSKEY RDATA broken into 2 octet groups. First the + RDATA (in wire format) is treated as a series of 2 octet groups, + these groups are then added together ignoring any carry bits. A + reference implementation of the key tag algorithm is as an ANSI C + function is given below with the RDATA portion of the DNSKEY RR is + used as input. It is not necessary to use the following reference + code verbatim, but the numerical value of the Key Tag MUST be + identical to what the reference implementation would generate for the + same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described here rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the DNSKEY RR. The code is written + for clarity, not efficiency. + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + + + +Arends, et al. Expires August 16, 2004 [Page 34] + +Internet-Draft DNSSEC Resource Records February 2004 + + + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the DNSKEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + +B.1 Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently than the + key tag for all other algorithms, for historical reasons. For a + DNSKEY RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 35] + +Internet-Draft DNSSEC Resource Records February 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires August 16, 2004 [Page 36] + +Internet-Draft DNSSEC Resource Records February 2004 + + + 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 August 16, 2004 [Page 37] + +