From fd6574dbc551faac89ae2ce6f3549fed51c24e49 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 30 Mar 2005 04:56:05 +0000 Subject: [PATCH] 4033: DNS Security Introduction and Requirements 4034: Resource Records for the DNS Security Extensions 4035: Protocol Modifications for the DNS Security Extensions --- doc/rfc/index | 3 + .../rfc4033.txt} | 1286 ++++----- .../rfc4034.txt} | 1574 +++++----- .../rfc4035.txt} | 2526 ++++++++--------- 4 files changed, 2307 insertions(+), 3082 deletions(-) rename doc/{draft/draft-ietf-dnsext-dnssec-intro-13.txt => rfc/rfc4033.txt} (56%) rename doc/{draft/draft-ietf-dnsext-dnssec-records-11.txt => rfc/rfc4034.txt} (61%) rename doc/{draft/draft-ietf-dnsext-dnssec-protocol-09.txt => rfc/rfc4035.txt} (66%) diff --git a/doc/rfc/index b/doc/rfc/index index e38265aa9f..1c6244ba54 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -95,3 +95,6 @@ 3833: Threat Analysis of the Domain Name System (DNS) 3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format 3901: DNS IPv6 Transport Operational Guidelines +4033: DNS Security Introduction and Requirements +4034: Resource Records for the DNS Security Extensions +4035: Protocol Modifications for the DNS Security Extensions diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-13.txt b/doc/rfc/rfc4033.txt similarity index 56% rename from doc/draft/draft-ietf-dnsext-dnssec-intro-13.txt rename to doc/rfc/rfc4033.txt index aadcd42eb7..7f0a464773 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-13.txt +++ b/doc/rfc/rfc4033.txt @@ -1,181 +1,132 @@ -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: April 10, 2005 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI + + + + +Network Working Group R. Arends +Request for Comments: 4033 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University S. Rose NIST - October 10, 2004 + March 2005 DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-13 -Status of this Memo +Status of This Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 10, 2005. + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). Abstract - - - -Arends, et al. Expires April 10, 2005 [Page 1] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This - document introduces these extensions, and describes their - capabilities and limitations. This document also discusses the - services that the DNS security extensions do and do not provide. - Last, this document describes the interrelationships between the - group of documents that collectively describe DNSSEC. + document introduces these extensions and describes their capabilities + and limitations. This document also discusses the services that the + DNS security extensions do and do not provide. Last, this document + describes the interrelationships between the documents that + collectively describe DNSSEC. + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 - 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 - 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 10 - 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 - 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 - 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 - 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 - 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 - 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 - 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 - 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 - 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . . 26 - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 2] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3 + 3. Services Provided by DNS Security . . . . . . . . . . . . . 7 + 3.1. Data Origin Authentication and Data Integrity . . . . 7 + 3.2. Authenticating Name and Type Non-Existence . . . . . . 9 + 4. Services Not Provided by DNS Security . . . . . . . . . . . 9 + 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9 + 6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10 + 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11 + 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12 + 8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13 + 8.2. New Temporal Dependency Issues for Zones . . . . . . . 13 + 9. Name Server Considerations . . . . . . . . . . . . . . . . . 13 + 10. DNS Security Document Family . . . . . . . . . . . . . . . . 14 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 15 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 14.1. Normative References . . . . . . . . . . . . . . . . . 17 + 14.2. Informative References . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21 1. Introduction This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and its two companion documents - ([I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the - security extensions defined in [RFC2535] and its predecessors. These - security extensions consist of a set of new resource record types and - modifications to the existing DNS protocol ([RFC1035]). The new - records and protocol modifications are not fully described in this - document, but are described in a family of documents outlined in - Section 10. Section 3 and Section 4 describe the capabilities and - limitations of the security extensions in greater detail. Section 5 - discusses the scope of the document set. Section 6, Section 7, - Section 8, and Section 9 discuss the effect that these security - extensions will have on resolvers, stub resolvers, zones and name - servers. + (DNSSEC). This document and its two companion documents ([RFC4034] + and [RFC4035]) update, clarify, and refine the security extensions + defined in [RFC2535] and its predecessors. These security extensions + consist of a set of new resource record types and modifications to + the existing DNS protocol ([RFC1035]). The new records and protocol + modifications are not fully described in this document, but are + described in a family of documents outlined in Section 10. Sections + 3 and 4 describe the capabilities and limitations of the security + extensions in greater detail. Section 5 discusses the scope of the + document set. Sections 6, 7, 8, and 9 discuss the effect that these + security extensions will have on resolvers, stub resolvers, zones, + and name servers. This document and its two companions obsolete [RFC2535], [RFC3008], [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and - [RFC3845]. This document set also updates, but does not obsolete, + [RFC3845]. This document set also updates but does not obsolete [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with DNSSEC. + + + +Arends, et al. Standards Track [Page 2] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + The DNS security extensions provide origin authentication and integrity protection for DNS data, as well as a means of public key distribution. These extensions do not provide confidentiality. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 3] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - 2. Definitions of Important DNSSEC Terms This section defines a number of terms used in this document set. - Since this is intended to be useful as a reference while reading the - rest of the document set, first-time readers may wish to skim this - section quickly, read the rest of this document, then come back to - this section. + Because this is intended to be useful as a reference while reading + the rest of the document set, first-time readers may wish to skim + this section quickly, read the rest of this document, and then come + back to this section. Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of @@ -185,7 +136,7 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 of another DNSKEY RR and this new DNSKEY RR is authenticated by matching the hash in the DS RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in - this set may be used to authenticate another DS RR and so forth + this set may be used to authenticate another DS RR, and so forth until the chain finally ends with a DNSKEY RR whose corresponding private key signs the desired DNS data. For example, the root DNSKEY RRset can be used to authenticate the DS RRset for @@ -193,7 +144,7 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 some "example." DNSKEY, and this DNSKEY's corresponding private key signs the "example." DNSKEY RRset. Private key counterparts of the "example." DNSKEY RRset sign data records such as - "www.example." as well as DS RRs for delegations such as + "www.example." and DS RRs for delegations such as "subzone.example." Authentication Key: A public key that a security-aware resolver has @@ -206,82 +157,86 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 authenticated public key to verify a DS RR and the DNSKEY RR to which the DS RR refers. Third, the resolver may be able to determine that a new public key has been signed by the private key - corresponding to another public key which the resolver has + corresponding to another public key that the resolver has verified. Note that the resolver must always be guided by local policy when deciding whether to authenticate a new public key, even if the local policy is simply to authenticate any new public key for which the resolver is able verify the signature. + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + Authoritative RRset: Within the context of a particular zone, an RRset is "authoritative" if and only if the owner name of the RRset lies within the subset of the name space that is at or below the zone apex and at or above the cuts that separate the zone from its children, if any. All RRsets at the zone apex are - - - -Arends, et al. Expires April 10, 2005 [Page 4] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - authoritative, except for certain RRsets at this domain name that, if present, belong to this zone's parent. These RRset could include a DS RRset, the NSEC RRset referencing this DS RRset (the "parental NSEC"), and RRSIG RRs associated with these RRsets, all of which are authoritative in the parent zone. Similarly, if this zone contains any delegation points, only the parental NSEC RRset, - DS RRsets, and any RRSIG RRs associated with these these RRsets - are authoritative for this zone. + DS RRsets, and any RRSIG RRs associated with these RRsets are + authoritative for this zone. Delegation Point: Term used to describe the name at the parental side of a zone cut. That is, the delegation point for "foo.example" would be the foo.example node in the "example" zone (as opposed to - the zone apex of the "foo.example" zone). See also: zone apex. + the zone apex of the "foo.example" zone). See also zone apex. Island of Security: Term used to describe a signed, delegated zone that does not have an authentication chain from its delegating parent. That is, there is no DS RR containing a hash of a DNSKEY - RR for the island in its delegating parent zone (see - [I-D.ietf-dnsext-dnssec-records]). An island of security is - served by security-aware name servers and may provide - authentication chains to any delegated child zones. Responses - from an island of security or its descendents can only be - authenticated if its authentication keys can be authenticated by - some trusted means out of band from the DNS protocol. + RR for the island in its delegating parent zone (see [RFC4034]). + An island of security is served by security-aware name servers and + may provide authentication chains to any delegated child zones. + Responses from an island of security or its descendents can only + be authenticated if its authentication keys can be authenticated + by some trusted means out of band from the DNS protocol. Key Signing Key (KSK): An authentication key that corresponds to a private key used to sign one or more other authentication keys for a given zone. Typically, the private key corresponding to a key signing key will sign a zone signing key, which in turn has a - corresponding private key which will sign other zone data. Local - policy may require the zone signing key to be changed frequently, - while the key signing key may have a longer validity period in - order to provide a more stable secure entry point into the zone. - Designating an authentication key as a key signing key is purely - an operational issue: DNSSEC validation does not distinguish - between key signing keys and other DNSSEC authentication keys, and - it is possible to use a single key as both a key signing key and a - zone signing key. Key signing keys are discussed in more detail - in [RFC3757]. Also see: zone signing key. + corresponding private key that will sign other zone data. Local + policy may require that the zone signing key be changed + frequently, while the key signing key may have a longer validity + period in order to provide a more stable secure entry point into + the zone. Designating an authentication key as a key signing key + is purely an operational issue: DNSSEC validation does not + distinguish between key signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. Key signing keys + are discussed in more detail in [RFC3757]. Also see zone signing + key. + + + + + + + +Arends, et al. Standards Track [Page 4] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + Non-Validating Security-Aware Stub Resolver: A security-aware stub - resolver which trusts one or more security-aware recursive name + resolver that trusts one or more security-aware recursive name servers to perform most of the tasks discussed in this document set on its behalf. In particular, a non-validating security-aware - stub resolver is an entity which sends DNS queries, receives DNS + stub resolver is an entity that sends DNS queries, receives DNS responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server which will + channel to a security-aware recursive name server that will provide these services on behalf of the security-aware stub - - - -Arends, et al. Expires April 10, 2005 [Page 5] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - - resolver. See also: security-aware stub resolver, validating + resolver. See also security-aware stub resolver, validating security-aware stub resolver. Non-Validating Stub Resolver: A less tedious term for a @@ -290,57 +245,56 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 Security-Aware Name Server: An entity acting in the role of a name server (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set. In - particular, a security-aware name server is an entity which + particular, a security-aware name server is an entity that receives DNS queries, sends DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and supports the RR types and message header bits defined in this document set. - Security-Aware Recursive Name Server: An entity which acts in both - the security-aware name server and security-aware resolver roles. - A more cumbersome equivalent phrase would be "a security-aware - name server which offers recursive service". + Security-Aware Recursive Name Server: An entity that acts in both the + security-aware name server and security-aware resolver roles. A + more cumbersome but equivalent phrase would be "a security-aware + name server that offers recursive service". Security-Aware Resolver: An entity acting in the role of a resolver - (defined in section 2.4 of [RFC1034]) which understands the DNS + (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set. In particular, - a security-aware resolver is an entity which sends DNS queries, + a security-aware resolver is an entity that sends DNS queries, receives DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and is capable of using the RR types and message header bits defined in this document set to provide DNSSEC services. Security-Aware Stub Resolver: An entity acting in the role of a stub - resolver (defined in section 5.3.1 of [RFC1034]) which has enough + resolver (defined in section 5.3.1 of [RFC1034]) that has enough of an understanding the DNS security extensions defined in this document set to provide additional services not available from a security-oblivious stub resolver. Security-aware stub resolvers - may be either "validating" or "non-validating" depending on + may be either "validating" or "non-validating", depending on whether the stub resolver attempts to verify DNSSEC signatures on its own or trusts a friendly security-aware name server to do so. - See also: validating stub resolver, non-validating stub resolver. + See also validating stub resolver, non-validating stub resolver. + + + + + +Arends, et al. Standards Track [Page 5] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + Security-Oblivious : An that is not "security-aware". - Signed Zone: A zone whose RRsets are signed and which contains + Signed Zone: A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), - Next Secure (NSEC) and (optionally) DS records. - - - - - - -Arends, et al. Expires April 10, 2005 [Page 6] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - + Next Secure (NSEC), and (optionally) DS records. Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed - DNS response. In general, a validating resolver will need to + DNS response. In general, a validating resolver will have to obtain the initial values of its trust anchors via some secure or trusted means outside the DNS protocol. Presence of a trust anchor also implies that the resolver should expect the zone to @@ -349,9 +303,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 Unsigned Zone: A zone that is not signed. Validating Security-Aware Stub Resolver: A security-aware resolver - that sends queries in recursive mode but which performs signature + that sends queries in recursive mode but that performs signature validation on its own rather than just blindly trusting an - upstream security-aware recursive name server. See also: + upstream security-aware recursive name server. See also security-aware stub resolver, non-validating security-aware stub resolver. @@ -359,19 +313,19 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 security-aware stub resolver. Zone Apex: Term used to describe the name at the child's side of a - zone cut. See also: delegation point. + zone cut. See also delegation point. Zone Signing Key (ZSK): An authentication key that corresponds to a - private key used to sign a zone. Typically a zone signing key + private key used to sign a zone. Typically, a zone signing key will be part of the same DNSKEY RRset as the key signing key whose corresponding private key signs this DNSKEY RRset, but the zone - signing key is used for a slightly different purpose, and may + signing key is used for a slightly different purpose and may differ from the key signing key in other ways, such as validity lifetime. Designating an authentication key as a zone signing key - is purely an operational issue: DNSSEC validation does not + is purely an operational issue; DNSSEC validation does not distinguish between zone signing keys and other DNSSEC authentication keys, and it is possible to use a single key as - both a key signing key and a zone signing key. See also: key + both a key signing key and a zone signing key. See also key signing key. @@ -381,16 +335,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 7] +Arends, et al. Standards Track [Page 6] -Internet-Draft DNSSEC Introduction and Requirements October 2004 +RFC 4033 DNS Security Introduction and Requirements March 2005 3. Services Provided by DNS Security @@ -401,52 +348,52 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 data. These mechanisms are described below. These mechanisms require changes to the DNS protocol. DNSSEC adds - four new resource record types: Resource Record Signature, DNS Public - Key, Delegation Signer, and Next Secure (RRSIG, DNSKEY, DS and NSEC) - and two new message header bits: Checking Disabled and Authenticated - Data (CD and AD). In order to support the larger DNS message sizes - that result from adding the DNSSEC RRs, DNSSEC also requires EDNS0 - support ([RFC2671]). Finally, DNSSEC requires support for the DNSSEC - OK (DO) EDNS header bit ([RFC3225]), so that a security-aware - resolver can indicate in its queries that it wishes to receive DNSSEC - RRs in response messages. + four new resource record types: Resource Record Signature (RRSIG), + DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure + (NSEC). It also adds two new message header bits: Checking Disabled + (CD) and Authenticated Data (AD). In order to support the larger DNS + message sizes that result from adding the DNSSEC RRs, DNSSEC also + requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support + for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a + security-aware resolver can indicate in its queries that it wishes to + receive DNSSEC RRs in response messages. These services protect against most of the threats to the Domain Name System described in [RFC3833]. Please see Section 12 for a discussion of the limitations of these extensions. -3.1 Data Origin Authentication and Data Integrity +3.1. Data Origin Authentication and Data Integrity DNSSEC provides authentication by associating cryptographically generated digital signatures with DNS RRsets. These digital signatures are stored in a new resource record, the RRSIG record. Typically, there will be a single private key that signs a zone's - data, but multiple keys are possible: for example, there may be keys + data, but multiple keys are possible. For example, there may be keys for each of several different digital signature algorithms. If a security-aware resolver reliably learns a zone's public key, it can authenticate that zone's signed data. An important DNSSEC concept is that the key that signs a zone's data is associated with the zone - itself and not with the zone's authoritative name servers (public + itself and not with the zone's authoritative name servers. (Public keys for DNS transaction authentication mechanisms may also appear in zones, as described in [RFC2931], but DNSSEC itself is concerned with object security of DNS data, not channel security of DNS transactions. The keys associated with transaction security may be - stored in different RR types. See [RFC3755] for details.). + stored in different RR types. See [RFC3755] for details.) A security-aware resolver can learn a zone's public key either by having a trust anchor configured into the resolver or by normal DNS resolution. To allow the latter, public keys are stored in a new type of resource record, the DNSKEY RR. Note that the private keys - used to sign zone data must be kept secure, and should be stored - offline when practical to do so. To discover a public key reliably - via DNS resolution, the target key itself needs to be signed by - either a configured authentication key or another key that has been + used to sign zone data must be kept secure and should be stored + offline when practical. To discover a public key reliably via DNS + resolution, the target key itself has to be signed by either a + configured authentication key or another key that has been -Arends, et al. Expires April 10, 2005 [Page 8] +Arends, et al. Standards Track [Page 7] -Internet-Draft DNSSEC Introduction and Requirements October 2004 +RFC 4033 DNS Security Introduction and Requirements March 2005 authenticated previously. Security-aware resolvers authenticate zone @@ -460,12 +407,12 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 authenticate the associated zone; if the configured key is a key signing key, it will authenticate a zone signing key. If the configured trust anchor is the hash of a key rather than the key - itself, the resolver may need to obtain the key via a DNS query. To + itself, the resolver may have to obtain the key via a DNS query. To help security-aware resolvers establish this authentication chain, security-aware name servers attempt to send the signature(s) needed to authenticate a zone's public key(s) in the DNS reply message along - with the public key itself, provided there is space available in the - message. + with the public key itself, provided that there is space available in + the message. The Delegation Signer (DS) RR type simplifies some of the administrative tasks involved in signing delegations across @@ -486,26 +433,26 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 on configured knowledge of the public key for the root. Local policy, however, may also allow a security-aware resolver to use one or more configured public keys (or hashes of public keys) other than - the root public key, or may not provide configured knowledge of the - root public key, or may prevent the resolver from using particular - public keys for arbitrary reasons even if those public keys are - properly signed with verifiable signatures. DNSSEC provides - mechanisms by which a security-aware resolver can determine whether - an RRset's signature is "valid" within the meaning of DNSSEC. In the - final analysis however, authenticating both DNS keys and data is a - matter of local policy, which may extend or even override the - protocol extensions defined in this document set. See Section 5 for - further discussion. + the root public key, may not provide configured knowledge of the root + public key, or may prevent the resolver from using particular public + keys for arbitrary reasons, even if those public keys are properly + signed with verifiable signatures. DNSSEC provides mechanisms by + which a security-aware resolver can determine whether an RRset's + signature is "valid" within the meaning of DNSSEC. In the final + analysis, however, authenticating both DNS keys and data is a matter + of local policy, which may extend or even override the protocol + extensions defined in this document set. See Section 5 for further + discussion. -Arends, et al. Expires April 10, 2005 [Page 9] +Arends, et al. Standards Track [Page 8] -Internet-Draft DNSSEC Introduction and Requirements October 2004 +RFC 4033 DNS Security Introduction and Requirements March 2005 -3.2 Authenticating Name and Type Non-Existence +3.2. Authenticating Name and Type Non-Existence The security mechanism described in Section 3.1 only provides a way to sign existing RRsets in a zone. The problem of providing negative @@ -513,53 +460,13 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 requires the use of another new resource record type, the NSEC record. The NSEC record allows a security-aware resolver to authenticate a negative reply for either name or type non-existence - via the same mechanisms used to authenticate other DNS replies. Use + with the same mechanisms used to authenticate other DNS replies. Use of NSEC records requires a canonical representation and ordering for domain names in zones. Chains of NSEC records explicitly describe - the gaps, or "empty space", between domain names in a zone, as well - as listing the types of RRsets present at existing names. Each NSEC - record is signed and authenticated using the mechanisms described in - Section 3.1. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 10] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - + the gaps, or "empty space", between domain names in a zone and list + the types of RRsets present at existing names. Each NSEC record is + signed and authenticated using the mechanisms described in Section + 3.1. 4. Services Not Provided by DNS Security @@ -582,41 +489,6 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 [RFC2845] and [RFC2931] address security operations that pertain to these transactions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 11] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - 5. Scope of the DNSSEC Document Set and Last Hop Issues The specification in this document set defines the behavior for zone @@ -624,194 +496,150 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 that the validating entities can unambiguously determine the state of the data. - A validating resolver can determine these 4 states: + A validating resolver can determine the following 4 states: + + Secure: The validating resolver has a trust anchor, has a chain of + trust, and is able to verify all the signatures in the response. + + + +Arends, et al. Standards Track [Page 9] + +RFC 4033 DNS Security Introduction and Requirements March 2005 - Secure: The validating resolver has a trust anchor, a chain of trust - and is able to verify all the signatures in the response. Insecure: The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the - non-existence of a DS record. That indicates that subsequent + non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure. A validating resolver - may have local policy to mark parts of the domain space as + may have a local policy to mark parts of the domain space as insecure. - Bogus: The validating resolver has a trust anchor and there is a - secure delegation which is indicating that subsidiary data will be - signed, but the response fails to validate due to one or more - reasons: missing signatures, expired signatures, signatures with - unsupported algorithms, data missing which the relevant NSEC RR - says should be present, and so forth. + Bogus: The validating resolver has a trust anchor and a secure + delegation indicating that subsidiary data is signed, but the + response fails to validate for some reason: missing signatures, + expired signatures, signatures with unsupported algorithms, data + missing that the relevant NSEC RR says should be present, and so + forth. - Indeterminate: There is no trust anchor which would indicate that a + Indeterminate: There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode. - This specification only defines how security aware name servers can + This specification only defines how security-aware name servers can signal non-validating stub resolvers that data was found to be bogus - (using RCODE=2, "Server Failure" -- see - [I-D.ietf-dnsext-dnssec-protocol]). + (using RCODE=2, "Server Failure"; see [RFC4035]). - There is a mechanism for security aware name servers to signal + There is a mechanism for security-aware name servers to signal security-aware stub resolvers that data was found to be secure (using - the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). + the AD bit; see [RFC4035]). This specification does not define a format for communicating why responses were found to be bogus or marked as insecure. The current signaling mechanism does not distinguish between indeterminate and - insecure. + insecure states. A method for signaling advanced error codes and policy between a - security aware stub resolver and security aware recursive nameservers - is a topic for future work, as is the interface between a security + security-aware stub resolver and security-aware recursive nameservers + is a topic for future work, as is the interface between a security- aware resolver and the applications that use it. Note, however, that - - - -Arends, et al. Expires April 10, 2005 [Page 12] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - the lack of the specification of such communication does not prohibit deployment of signed zones or the deployment of security aware recursive name servers that prohibit propagation of bogus data to the applications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 13] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - 6. Resolver Considerations - A security-aware resolver needs to be able to perform cryptographic + A security-aware resolver has to be able to perform cryptographic functions necessary to verify digital signatures using at least the mandatory-to-implement algorithm(s). Security-aware resolvers must also be capable of forming an authentication chain from a newly learned zone back to an authentication key, as described above. This process might require additional queries to intermediate DNS zones to - obtain necessary DNSKEY, DS and RRSIG records. A security-aware + + + +Arends, et al. Standards Track [Page 10] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + obtain necessary DNSKEY, DS, and RRSIG records. A security-aware resolver should be configured with at least one trust anchor as the starting point from which it will attempt to establish authentication chains. If a security-aware resolver is separated from the relevant authoritative name servers by a recursive name server or by any sort - of intermediary device which acts as a proxy for DNS, and if the + of intermediary device that acts as a proxy for DNS, and if the recursive name server or intermediary device is not security-aware, the security-aware resolver may not be capable of operating in a secure mode. For example, if a security-aware resolver's packets are routed through a network address translation (NAT) device that - includes a DNS proxy which is not security-aware, the security-aware + includes a DNS proxy that is not security-aware, the security-aware resolver may find it difficult or impossible to obtain or validate signed DNS data. The security-aware resolver may have a particularly - difficult time obtaining DS RRs in such a case, since DS RRs do not + difficult time obtaining DS RRs in such a case, as DS RRs do not follow the usual DNS rules for ownership of RRs at zone cuts. Note - that this problem is not specific to NATs -- any security-oblivious - DNS software of any kind between the security-aware resolver and the + that this problem is not specific to NATs: any security-oblivious DNS + software of any kind between the security-aware resolver and the authoritative name servers will interfere with DNSSEC. If a security-aware resolver must rely on an unsigned zone or a name server that is not security aware, the resolver may not be able to - validate DNS responses, and will need a local policy on whether to + validate DNS responses and will need a local policy on whether to accept unverified responses. A security-aware resolver should take a signature's validation period into consideration when determining the TTL of data in its cache, to avoid caching signed data beyond the validity period of the - signature, but should also allow for the possibility that the - security-aware resolver's own clock is wrong. Thus, a security-aware - resolver which is part of a security-aware recursive name server will - need to pay careful attention to the DNSSEC "checking disabled" (CD) - bit ([I-D.ietf-dnsext-dnssec-records]). This is in order to avoid + signature. However, it should also allow for the possibility that + the security-aware resolver's own clock is wrong. Thus, a + security-aware resolver that is part of a security-aware recursive + name server will have to pay careful attention to the DNSSEC + "checking disabled" (CD) bit ([RFC4034]). This is in order to avoid blocking valid signatures from getting through to other - security-aware resolvers which are clients of this recursive name - server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure - recursive server handles queries with the CD bit set. - - - - - -Arends, et al. Expires April 10, 2005 [Page 14] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - + security-aware resolvers that are clients of this recursive name + server. See [RFC4035] for how a secure recursive server handles + queries with the CD bit set. 7. Stub Resolver Considerations Although not strictly required to do so by the protocol, most DNS queries originate from stub resolvers. Stub resolvers, by - definition, are minimal DNS resolvers which use recursive query mode + definition, are minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server. Given the widespread use of stub resolvers, the DNSSEC + + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + architecture has to take stub resolvers into account, but the security features needed in a stub resolver differ in some respects - from those needed in a full security-aware resolver. + from those needed in a security-aware iterative resolver. - Even a security-oblivious stub resolver may get some benefit from - DNSSEC if the recursive name servers it uses are security-aware, but - for the stub resolver to place any real reliance on DNSSEC services, - the stub resolver must trust both the recursive name servers in - question and the communication channels between itself and those name - servers. The first of these issues is a local policy issue: in - essence, a security-oblivious stub resolver has no real choice but to - place itself at the mercy of the recursive name servers that it uses, - since it does not perform DNSSEC validity checks on its own. The - second issue requires some kind of channel security mechanism; proper - use of DNS transaction authentication mechanisms such as SIG(0) - ([RFC2931]) or TSIG ([RFC2845]) would suffice, as would appropriate - use of IPsec, and particular implementations may have other choices - available, such as operating system specific interprocess - communication mechanisms. Confidentiality is not needed for this - channel, but data integrity and message authentication are. + Even a security-oblivious stub resolver may benefit from DNSSEC if + the recursive name servers it uses are security-aware, but for the + stub resolver to place any real reliance on DNSSEC services, the stub + resolver must trust both the recursive name servers in question and + the communication channels between itself and those name servers. + The first of these issues is a local policy issue: in essence, a + security-oblivious stub resolver has no choice but to place itself at + the mercy of the recursive name servers that it uses, as it does not + perform DNSSEC validity checks on its own. The second issue requires + some kind of channel security mechanism; proper use of DNS + transaction authentication mechanisms such as SIG(0) ([RFC2931]) or + TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec. + Particular implementations may have other choices available, such as + operating system specific interprocess communication mechanisms. + Confidentiality is not needed for this channel, but data integrity + and message authentication are. A security-aware stub resolver that does trust both its recursive name servers and its communication channel to them may choose to @@ -823,35 +651,32 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 There is one more step that a security-aware stub resolver can take if, for whatever reason, it is not able to establish a useful trust - relationship with the recursive name servers which it uses: it can - perform its own signature validation, by setting the Checking - Disabled (CD) bit in its query messages. A validating stub resolver - is thus able to treat the DNSSEC signatures as a trust relationship - between the zone administrator and the stub resolver itself. - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 15] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - + relationship with the recursive name servers that it uses: it can + perform its own signature validation by setting the Checking Disabled + (CD) bit in its query messages. A validating stub resolver is thus + able to treat the DNSSEC signatures as trust relationships between + the zone administrators and the stub resolver itself. 8. Zone Considerations There are several differences between signed and unsigned zones. A signed zone will contain additional security-related records (RRSIG, - DNSKEY, DS and NSEC records). RRSIG and NSEC records may be + DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be generated by a signing process prior to serving the zone. The RRSIG records that accompany zone data have defined inception and - expiration times, which establish a validity period for the - signatures and the zone data the signatures cover. + expiration times that establish a validity period for the signatures + and the zone data the signatures cover. -8.1 TTL values vs. RRSIG validity period + + + + +Arends, et al. Standards Track [Page 12] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +8.1. TTL Values vs. RRSIG Validity Period It is important to note the distinction between a RRset's TTL value and the signature validity period specified by the RRSIG RR covering @@ -859,114 +684,87 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 TTL value, which is intended to maintain database coherency in caches. A caching resolver purges RRsets from its cache no later than the end of the time period specified by the TTL fields of those - RRsets, regardless of whether or not the resolver is security-aware. + RRsets, regardless of whether the resolver is security-aware. - The inception and expiration fields in the RRSIG RR - ([I-D.ietf-dnsext-dnssec-records]), on the other hand, specify the - time period during which the signature can be used to validate the - covered RRset. The signatures associated with signed zone data are - only valid for the time period specified by these fields in the RRSIG - RRs in question. TTL values cannot extend the validity period of - signed RRsets in a resolver's cache, but the resolver may use the - time remaining before expiration of the signature validity period of - a signed RRset as an upper bound for the TTL of the signed RRset and - its associated RRSIG RR in the resolver's cache. + The inception and expiration fields in the RRSIG RR ([RFC4034]), on + the other hand, specify the time period during which the signature + can be used to validate the covered RRset. The signatures associated + with signed zone data are only valid for the time period specified by + these fields in the RRSIG RRs in question. TTL values cannot extend + the validity period of signed RRsets in a resolver's cache, but the + resolver may use the time remaining before expiration of the + signature validity period of a signed RRset as an upper bound for the + TTL of the signed RRset and its associated RRSIG RR in the resolver's + cache. -8.2 New Temporal Dependency Issues for Zones +8.2. New Temporal Dependency Issues for Zones - Information in a signed zone has a temporal dependency which did not + Information in a signed zone has a temporal dependency that did not exist in the original DNS protocol. A signed zone requires regular maintenance to ensure that each RRset in the zone has a current valid RRSIG RR. The signature validity period of an RRSIG RR is an interval during which the signature for one particular signed RRset can be considered valid, and the signatures of different RRsets in a zone may expire at different times. Re-signing one or more RRsets in - a zone will change one or more RRSIG RRs, which in turn will require + a zone will change one or more RRSIG RRs, which will in turn require incrementing the zone's SOA serial number to indicate that a zone change has occurred and re-signing the SOA RRset itself. Thus, re-signing any RRset in a zone may also trigger DNS NOTIFY messages - and zone transfers operations. - - - - - - -Arends, et al. Expires April 10, 2005 [Page 16] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - + and zone transfer operations. 9. Name Server Considerations A security-aware name server should include the appropriate DNSSEC - records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from - resolvers which have signaled their willingness to receive such + records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries + from resolvers that have signaled their willingness to receive such records via use of the DO bit in the EDNS header, subject to message - size limitations. Since inclusion of these DNSSEC RRs could easily + size limitations. Because inclusion of these DNSSEC RRs could easily cause UDP message truncation and fallback to TCP, a security-aware name server must also support the EDNS "sender's UDP payload" mechanism. + + + + +Arends, et al. Standards Track [Page 13] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + If possible, the private half of each DNSSEC key pair should be kept offline, but this will not be possible for a zone for which DNS dynamic update has been enabled. In the dynamic update case, the primary master server for the zone will have to re-sign the zone when - updated, so the private key corresponding to the zone signing key - will have to be kept online. This is an example of a situation where - the ability to separate the zone's DNSKEY RRset into zone signing - key(s) and key signing key(s) may be useful, since the key signing - key(s) in such a case can still be kept offline and may have a longer - useful lifetime than the zone signing key(s). - - DNSSEC, by itself, is not enough to protect the integrity of an - entire zone during zone transfer operations, since even a signed zone - contains some unsigned, nonauthoritative data if the zone has any - children. Therefore, zone maintenance operations will require some - additional mechanisms (most likely some form of channel security, - such as TSIG, SIG(0), or IPsec). - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 17] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 + it is updated, so the private key corresponding to the zone signing + key will have to be kept online. This is an example of a situation + in which the ability to separate the zone's DNSKEY RRset into zone + signing key(s) and key signing key(s) may be useful, as the key + signing key(s) in such a case can still be kept offline and may have + a longer useful lifetime than the zone signing key(s). + By itself, DNSSEC is not enough to protect the integrity of an entire + zone during zone transfer operations, as even a signed zone contains + some unsigned, nonauthoritative data if the zone has any children. + Therefore, zone maintenance operations will require some additional + mechanisms (most likely some form of channel security, such as TSIG, + SIG(0), or IPsec). 10. DNS Security Document Family The DNSSEC document set can be partitioned into several main groups, under the larger umbrella of the DNS base protocol documents. - The "DNSSEC protocol document set" refers to the three documents - which form the core of the DNS security extensions: - 1. DNS Security Introduction and Requirements (this document) - 2. Resource Records for DNS Security Extensions - [I-D.ietf-dnsext-dnssec-records] - 3. Protocol Modifications for the DNS Security Extensions - [I-D.ietf-dnsext-dnssec-protocol] + The "DNSSEC protocol document set" refers to the three documents that + form the core of the DNS security extensions: - Additionally, any document that would add to, or change the core DNS + 1. DNS Security Introduction and Requirements (this document) + + 2. Resource Records for DNS Security Extensions [RFC4034] + + 3. Protocol Modifications for the DNS Security Extensions [RFC4035] + + Additionally, any document that would add to or change the core DNS Security extensions would fall into this category. This includes any future work on the communication between security-aware stub resolvers and upstream security-aware recursive name servers. @@ -976,103 +774,43 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 signature algorithms should be implemented to fit the DNSSEC resource record format. Each document in this set deals with a specific digital signature algorithm. Please see the appendix on "DNSSEC - Algorithm and Digest Types" in [I-D.ietf-dnsext-dnssec-records] for a - list of the algorithms that were defined at the time this core - specification was written. + Algorithm and Digest Types" in [RFC4034] for a list of the algorithms + that were defined when this core specification was written. The "Transaction Authentication Protocol" document set refers to the group of documents that deal with DNS message authentication, - including secret key establishment and verification. While not + including secret key establishment and verification. Although not + + + +Arends, et al. Standards Track [Page 14] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + strictly part of the DNSSEC specification as defined in this set of documents, this group is noted because of its relationship to DNSSEC. The final document set, "New Security Uses", refers to documents that seek to use proposed DNS Security extensions for other security related purposes. DNSSEC does not provide any direct security for - these new uses, but may be used to support them. Documents that fall - in this category include the use of DNS in the storage and - distribution of certificates ([RFC2538]). - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 18] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - + these new uses but may be used to support them. Documents that fall + in this category include those describing the use of DNS in the + storage and distribution of certificates ([RFC2538]). 11. IANA Considerations This overview document introduces no new IANA considerations. Please - see [I-D.ietf-dnsext-dnssec-records] for a complete review of the - IANA considerations introduced by DNSSEC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 19] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - + see [RFC4034] for a complete review of the IANA considerations + introduced by DNSSEC. 12. Security Considerations - This document introduces the DNS security extensions and describes - the document set that contains the new security records and DNS - protocol modifications. The extensions provide data origin - authentication and data integrity using digital signatures over - resource record sets. This section discusses the limitations of - these extensions. + This document introduces DNS security extensions and describes the + document set that contains the new security records and DNS protocol + modifications. The extensions provide data origin authentication and + data integrity using digital signatures over resource record sets. + This section discusses the limitations of these extensions. In order for a security-aware resolver to validate a DNS response, all zones along the path from the trusted starting point to the zone @@ -1081,10 +819,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 security-aware, as defined in this document set. A security-aware resolver cannot verify responses originating from an unsigned zone, from a zone not served by a security-aware name server, or for any - DNS data which the resolver is only able to obtain through a - recursive name server which is not security-aware. If there is a - break in the authentication chain such that a security-aware resolver - cannot obtain and validate the authentication keys it needs, then the + DNS data that the resolver is only able to obtain through a recursive + name server that is not security-aware. If there is a break in the + authentication chain such that a security-aware resolver cannot + obtain and validate the authentication keys it needs, then the security-aware resolver cannot validate the affected DNS data. This document briefly discusses other methods of adding security to a @@ -1094,10 +832,18 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 per se. A non-validating security-aware stub resolver, by definition, does - not perform DNSSEC signature validation on its own, and thus is + not perform DNSSEC signature validation on its own and thus is vulnerable both to attacks on (and by) the security-aware recursive - name servers which perform these checks on its behalf and also to - attacks on its communication with those security-aware recursive name + name servers that perform these checks on its behalf and to attacks + on its communication with those security-aware recursive name + + + +Arends, et al. Standards Track [Page 15] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + servers. Non-validating security-aware stub resolvers should use some form of channel security to defend against the latter threat. The only known defense against the former threat would be for the @@ -1108,38 +854,30 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 DNSSEC does not protect against denial of service attacks. DNSSEC makes DNS vulnerable to a new class of denial of service attacks based on cryptographic operations against security-aware resolvers - and security-aware name servers, since an attacker can attempt to use + and security-aware name servers, as an attacker can attempt to use DNSSEC mechanisms to consume a victim's resources. This class of attacks takes at least two forms. An attacker may be able to consume resources in a security-aware resolver's signature validation code by tampering with RRSIG RRs in response messages or by constructing - - - -Arends, et al. Expires April 10, 2005 [Page 20] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - needlessly complex signature chains. An attacker may also be able to - consume resources in a security-aware name server which supports DNS + consume resources in a security-aware name server that supports DNS dynamic update, by sending a stream of update messages that force the security-aware name server to re-sign some RRsets in the zone more frequently than would otherwise be necessary. - DNSSEC does not provide confidentiality, due to a deliberate design - choice. + Due to a deliberate design choice, DNSSEC does not provide + confidentiality. DNSSEC introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in sequence to - obtain all the names in a zone. While not an attack on the DNS - itself, this could allow an attacker to map network hosts or other - resources by enumerating the contents of a zone. + obtain all the names in a zone. Although this is not an attack on + the DNS itself, it could allow an attacker to map network hosts or + other resources by enumerating the contents of a zone. - DNSSEC introduces significant additional complexity to the DNS, and + DNSSEC introduces significant additional complexity to the DNS and thus introduces many new opportunities for implementation bugs and misconfigured zones. In particular, enabling DNSSEC signature validation in a resolver may cause entire legitimate zones to become @@ -1148,47 +886,35 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 DNSSEC does not protect against tampering with unsigned zone data. Non-authoritative data at zone cuts (glue and NS RRs in the parent zone) are not signed. This does not pose a problem when validating - the authentication chain, but does mean that the non-authoritative + the authentication chain, but it does mean that the non-authoritative data itself is vulnerable to tampering during zone transfer operations. Thus, while DNSSEC can provide data origin authentication and data integrity for RRsets, it cannot do so for zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be used to protect zone transfer operations. - Please see [I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations. - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 21] +Arends, et al. Standards Track [Page 16] -Internet-Draft DNSSEC Introduction and Requirements October 2004 +RFC 4033 DNS Security Introduction and Requirements March 2005 + Please see [RFC4034] and [RFC4035] for additional security + considerations. + 13. Acknowledgements This document was created from the input and ideas of the members of - the DNS Extensions Working Group. While explicitly listing everyone - who has contributed during the decade during which DNSSEC has been - under development would be an impossible task, the editors would + the DNS Extensions Working Group. Although explicitly listing + everyone who has contributed during the decade in which DNSSEC has + been under development would be impossible, the editors would particularly like to thank the following people for their contributions to and comments on this document set: Jaap Akkerhuis, Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, - Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip + Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, @@ -1202,52 +928,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 No doubt the above list is incomplete. We apologize to anyone we left out. - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - 14. References -14.1 Normative References - - [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-06 (work in - progress), May 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-08 (work in progress), - May 2004. +14.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. @@ -1255,8 +938,8 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. @@ -1264,17 +947,34 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. + + + + +Arends, et al. Standards Track [Page 17] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. -14.2 Informative References + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for DNS Security Extensions", RFC + 4034, March 2005. - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +14.2. Informative References + + [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. @@ -1282,22 +982,15 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. + [RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates + in the Domain Name System (DNS)", RFC 2538, March 1999. - -Arends, et al. Expires April 10, 2005 [Page 23] - -Internet-Draft DNSSEC Introduction and Requirements October 2004 - - - [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in - the Domain Name System (DNS)", RFC 2538, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. @@ -1311,6 +1004,14 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. + + + +Arends, et al. Standards Track [Page 18] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003. @@ -1318,10 +1019,11 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 (RR)", RFC 3658, December 2003. [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", RFC 3755, April 2004. + Signer (DS)", RFC 3755, May 2004. - [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", RFC 3757, April 2004. + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. @@ -1340,17 +1042,38 @@ Internet-Draft DNSSEC Introduction and Requirements October 2004 -Arends, et al. Expires April 10, 2005 [Page 24] + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 19] -Internet-Draft DNSSEC Introduction and Requirements October 2004 +RFC 4033 DNS Security Introduction and Requirements March 2005 Authors' Addresses Roy Arends Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede + Brouwerijstraat 1 + 7523 XC Enschede NL EMail: roy.arends@telin.nl @@ -1375,12 +1098,11 @@ Authors' Addresses Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 - EMail: masseyd@isi.edu + EMail: massey@cs.colostate.edu Scott Rose @@ -1396,12 +1118,29 @@ Authors' Addresses -Arends, et al. Expires April 10, 2005 [Page 25] + +Arends, et al. Standards Track [Page 20] -Internet-Draft DNSSEC Introduction and Requirements October 2004 +RFC 4033 DNS Security Introduction and Requirements March 2005 -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -1422,29 +1161,10 @@ Intellectual Property Statement The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment +Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. @@ -1452,6 +1172,8 @@ Acknowledgment -Arends, et al. Expires April 10, 2005 [Page 26] - + + +Arends, et al. Standards Track [Page 21] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-11.txt b/doc/rfc/rfc4034.txt similarity index 61% rename from doc/draft/draft-ietf-dnsext-dnssec-records-11.txt rename to doc/rfc/rfc4034.txt index 4f0feabf6d..6a12c6b8ef 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-11.txt +++ b/doc/rfc/rfc4034.txt @@ -1,63 +1,39 @@ -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: April 10, 2005 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI + + + + +Network Working Group R. Arends +Request for Comments: 4034 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University S. Rose NIST - October 10, 2004 + March 2005 Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-11 -Status of this Memo +Status of This Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 10, 2005. + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). Abstract - - - -Arends, et al. Expires April 10, 2005 [Page 1] - -Internet-Draft DNSSEC Resource Records October 2004 - - - This document is part of a family of documents that describes the DNS + This document is part of a family of documents that describe 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 @@ -69,105 +45,89 @@ Internet-Draft DNSSEC Resource Records October 2004 This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4034 DNSSEC Resource Records March 2005 + + Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5 - 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5 - 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6 - 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6 - 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6 - 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6 - 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6 - 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7 - 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8 - 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10 - 3.1.5 Signature Expiration and Inception Fields . . . . . . 10 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11 - 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12 - 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13 - 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14 - 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14 - 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15 - 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 16 - 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 16 - 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 16 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . 3 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4 + 2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4 + 2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4 + 2.1.2. The Protocol Field . . . . . . . . . . . . . . 5 + 2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5 + 2.1.4. The Public Key Field . . . . . . . . . . . . . 5 + 2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5 + 2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5 + 2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6 + 3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7 + 3.1.1. The Type Covered Field . . . . . . . . . . . . 7 + 3.1.2. The Algorithm Number Field . . . . . . . . . . 8 + 3.1.3. The Labels Field . . . . . . . . . . . . . . . 8 + 3.1.4. Original TTL Field . . . . . . . . . . . . . . 8 + 3.1.5. Signature Expiration and Inception Fields. . . 9 + 3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9 + 3.1.7. The Signer's Name Field. . . . . . . . . . . . 9 + 3.1.8. The Signature Field. . . . . . . . . . . . . . 9 + 3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10 + 3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12 + 4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13 + 4.1.1. The Next Domain Name Field . . . . . . . . . . 13 + 4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13 + 4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14 + 4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14 + 4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15 + 5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16 + 5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16 + 5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16 + 5.1.3. The Digest Type Field. . . . . . . . . . . . . 17 + 5.1.4. The Digest Field . . . . . . . . . . . . . . . 17 + 5.2. Processing of DS RRs When Validating Responses . . . . 17 + 5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17 + 5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18 + 6. Canonical Form and Order of Resource Records . . . . . . . . 18 + 6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18 + 6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19 + 6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20 + 8. Security Considerations. . . . . . . . . . . . . . . . . . . 21 -Arends, et al. Expires April 10, 2005 [Page 2] +Arends, et al. Standards Track [Page 2] -Internet-Draft DNSSEC Resource Records October 2004 +RFC 4034 DNSSEC Resource Records March 2005 - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19 - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19 - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19 - 5.2 Processing of DS RRs When Validating Responses . . . . . . 19 - 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20 - 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 20 - 6. Canonical Form and Order of Resource Records . . . . . . . . . 21 - 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21 - 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 21 - 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 22 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 - 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29 - A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31 - B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32 - Intellectual Property and Copyright Statements . . . . . . . . 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 3] - -Internet-Draft DNSSEC Resource Records October 2004 - + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . 23 + A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24 + A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24 + A.1.1. Private Algorithm Types. . . . . . . . . . . . 25 + A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25 + B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25 + B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29 1. Introduction @@ -177,32 +137,29 @@ Internet-Draft DNSSEC Resource Records October 2004 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 +1.1. Background and Related Documents - This document is part of a family of documents that define DNSSEC, - which should be read together as a set. + This document is part of a family of documents defining DNSSEC, which + should be read together as a set. - [I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and - definition of common terms; the reader is assumed to be familiar with - this document. [I-D.ietf-dnsext-dnssec-intro] also contains a list - of other documents updated by and obsoleted by this document set. + [RFC4033] contains an introduction to DNSSEC and definition of common + terms; the reader is assumed to be familiar with this document. + [RFC4033] also contains a list of other documents updated by and + obsoleted by this document set. - [I-D.ietf-dnsext-dnssec-protocol] defines the DNSSEC protocol - operations. + [RFC4035] defines the DNSSEC protocol operations. The reader is also assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that update them, particularly [RFC2181] and [RFC2308]. - This document defines the DNSSEC resource records. + This document defines the DNSSEC resource records. All numeric DNS + type codes given in this document are decimal integers. - All numeric DNS type codes given in this document are decimal - integers. - -1.2 Reserved Words +1.2. Reserved Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -210,19 +167,9 @@ Internet-Draft DNSSEC Resource Records October 2004 - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 4] +Arends, et al. Standards Track [Page 3] -Internet-Draft DNSSEC Resource Records October 2004 +RFC 4034 DNSSEC Resource Records March 2005 2. The DNSKEY Resource Record @@ -230,11 +177,11 @@ Internet-Draft DNSSEC Resource Records October 2004 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 - validate signatures covering the RRsets in the zone, and thus - authenticate them. + described in [RFC4035]: A zone signs its authoritative RRsets by + using a private key and stores the corresponding public key in a + DNSKEY RR. A resolver can then use the public key to validate + signatures covering the RRsets in the zone, and thus to authenticate + them. 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 @@ -246,7 +193,7 @@ Internet-Draft DNSSEC Resource Records October 2004 The DNSKEY RR has no special TTL requirements. -2.1 DNSKEY RDATA Wire Format +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 @@ -262,88 +209,86 @@ Internet-Draft DNSSEC Resource Records October 2004 / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -2.1.1 The Flags Field +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 and MUST NOT be - used to verify RRSIGs that cover RRsets. + 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 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 [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a - - - -Arends, et al. Expires April 10, 2005 [Page 5] - -Internet-Draft DNSSEC Resource Records October 2004 - - 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; validators MUST NOT alter - their behavior during the signature validation process in any way - based on the setting of this bit. This also means a DNSKEY RR with - the SEP bit set would also need the Zone Key flag set in order to - legally be able to generate signatures. A DNSKEY RR with the SEP set - and the Zone Key flag not set MUST NOT be used to verify RRSIGs that - cover RRsets. + + + +Arends, et al. Standards Track [Page 4] + +RFC 4034 DNSSEC Resource Records March 2005 + + + intended to be a hint to zone signing or debugging software as to the + intended use of this DNSKEY record; validators MUST NOT alter their + behavior during the signature validation process in any way based on + the setting of this bit. This also means that a DNSKEY RR with the + SEP bit set would also need the Zone Key flag set in order to be able + to generate signatures legally. A DNSKEY RR with the SEP set and the + Zone Key flag not set MUST NOT be used to verify RRSIGs that cover + RRsets. 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. + creation of the DNSKEY RR and MUST be ignored upon receipt. -2.1.2 The Protocol Field +2.1.2. The Protocol Field - The Protocol Field MUST have value 3 and the DNSKEY RR MUST be - treated as invalid during signature verification if found to be some - value other than 3. + The Protocol Field MUST have value 3, and the DNSKEY RR MUST be + treated as invalid during signature verification if it is found to be + some value other than 3. -2.1.3 The Algorithm Field +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 +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 + depends on the algorithm of the key being stored and is described in separate documents. -2.1.5 Notes on DNSKEY RDATA Design +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 +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. Given the currently defined flags, the possible values are: 0, 256, - or 257. + and 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 - - - -Arends, et al. Expires April 10, 2005 [Page 6] - -Internet-Draft DNSSEC Resource Records October 2004 - - integer or as an algorithm mnemonic as specified in Appendix A.1. + + +Arends, et al. Standards Track [Page 5] + +RFC 4034 DNSSEC Resource Records March 2005 + + The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [RFC3548]. -2.3 DNSKEY RR Example +2.3. DNSKEY RR Example The following DNSKEY RR stores a DNS zone key for example.com. @@ -363,45 +308,15 @@ Internet-Draft DNSSEC Resource Records October 2004 RSA/SHA1 public key field is defined in [RFC3110]. The remaining text is a Base64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 7] - -Internet-Draft DNSSEC Resource Records October 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 validator - 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. + process described in [RFC4035]. A validator 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 @@ -412,11 +327,19 @@ Internet-Draft DNSSEC Resource Records October 2004 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 + [RFC1034], which 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 signed zone. + + + +Arends, et al. Standards Track [Page 6] + +RFC 4034 DNSSEC Resource Records March 2005 + + The Type value for the RRSIG RR type is 46. The RRSIG RR is class independent. @@ -425,11 +348,11 @@ Internet-Draft DNSSEC Resource Records October 2004 The TTL value of an RRSIG RR MUST 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 + of individual RRs within a RRset: individual RRSIG RRs with the same owner name will have different TTL values if the RRsets they cover have different TTL values. -3.1 RRSIG RDATA Wire Format +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 @@ -437,18 +360,6 @@ Internet-Draft DNSSEC Resource Records October 2004 Inception field, a 2 octet Key tag, the Signer's Name field, and the Signature field. - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 8] - -Internet-Draft DNSSEC Resource Records October 2004 - - 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -469,41 +380,43 @@ Internet-Draft DNSSEC Resource Records October 2004 / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -3.1.1 The Type Covered Field +3.1.1. The Type Covered Field The Type Covered field identifies the type of the RRset that is covered by this RRSIG record. -3.1.2 The Algorithm Number Field + + + + + + +Arends, et al. Standards Track [Page 7] + +RFC 4034 DNSSEC Resource Records March 2005 + + +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 +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 a validator - uses it to 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. + uses it to determine whether 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. - - - -Arends, et al. Expires April 10, 2005 [Page 9] - -Internet-Draft DNSSEC Resource Records October 2004 - + validator will have to reconstruct the original owner name in order + to validate the signature. [RFC4035] 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 @@ -515,20 +428,31 @@ Internet-Draft DNSSEC Resource Records October 2004 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. + RRset's owner name when the signature is generated or verified. -3.1.4 Original TTL Field +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 validator requires the original TTL. - [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original - TTL field value to reconstruct the original TTL. + signature, a validator requires the original TTL. [RFC4035] + describes how to use the Original TTL field value to reconstruct the + original TTL. -3.1.5 Signature Expiration and Inception Fields + + + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4034 DNSSEC Resource Records March 2005 + + +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 @@ -538,51 +462,51 @@ Internet-Draft DNSSEC Resource Records October 2004 The Signature Expiration and Inception field values specify a date and time in the form of 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 + byte order. The longest interval that 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 + have an Expiration field value that 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. + 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 +3.1.6. The Key Tag Field The Key Tag field contains the key tag value of the DNSKEY RR that validates this signature, in network byte order. Appendix B explains how to calculate Key Tag values. - - -Arends, et al. Expires April 10, 2005 [Page 10] - -Internet-Draft DNSSEC Resource Records October 2004 - - -3.1.7 The Signer's Name Field +3.1.7. The Signer's Name Field The Signer's Name field value identifies the owner name of the DNSKEY - RR which a validator is supposed to use to validate this signature. + RR that a validator is supposed to 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. -3.1.8 The Signature Field +3.1.8. The Signature Field The Signature field contains the cryptographic signature that 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. + use, and these formats are described in separate companion documents. -3.1.8.1 Signature Calculation +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: + (see Section 6), and the set RR(1),...RR(n) is signed as follows: + + + +Arends, et al. Standards Track [Page 9] + +RFC 4034 DNSSEC Resource Records March 2005 + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where @@ -609,36 +533,37 @@ Internet-Draft DNSSEC Resource Records October 2004 RRSIG Original TTL Field; Any DNS names in the RDATA field of each RR MUST be in - - - -Arends, et al. Expires April 10, 2005 [Page 11] - -Internet-Draft DNSSEC Resource Records October 2004 - - canonical form; and The RRset MUST be sorted in canonical order. - See Section 6.2 and Section 6.3 for details on canonical form and - ordering of RRsets. + See Sections 6.2 and 6.3 for details on canonical form and ordering + of RRsets. -3.2 The RRSIG RR Presentation Format +3.2. The RRSIG RR Presentation Format The presentation format of the RDATA portion is as follows: - The Type Covered field is represented as a RR type mnemonic. When + The Type Covered field is represented as an RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in - [RFC3597] (section 5) MUST be used. + [RFC3597], Section 5, MUST be used. The Algorithm field value MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix + 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. + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4034 DNSSEC Resource Records March 2005 + + The Original TTL field value MUST be represented as an unsigned decimal integer. @@ -646,14 +571,16 @@ Internet-Draft DNSSEC Resource Records October 2004 represented either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where: + YYYY is the year (0001-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); + HH is the hour, in 24 hour notation (00-23); mm is the minute (00-59); and SS is the second (00-59). - Note that it is always be possible to distinguish between these two - formats, because the YYYYMMDDHHmmSS format will always be exactly 14 + + Note that it is always possible to distinguish between these two + formats because the YYYYMMDDHHmmSS format will always be exactly 14 digits, while the decimal representation of a 32-bit unsigned integer can never be longer than 10 digits. @@ -665,15 +592,7 @@ Internet-Draft DNSSEC Resource Records October 2004 signature. Whitespace is allowed within the Base64 text. See Section 2.2. - - - -Arends, et al. Expires April 10, 2005 [Page 12] - -Internet-Draft DNSSEC Resource Records October 2004 - - -3.3 RRSIG RR Example +3.3. RRSIG RR Example The following RRSIG RR stores the signature for the A RRset of host.example.com: @@ -692,65 +611,48 @@ Internet-Draft DNSSEC Resource Records October 2004 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 + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4034 DNSSEC Resource Records March 2005 + + 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 + indicates 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 April 10, 2005 [Page 13] - -Internet-Draft DNSSEC Resource Records October 2004 - + Algorithm, Signer's Name, and Key Tag indicate that this signature + can be authenticated using an example.com zone DNSKEY RR whose + algorithm is 5 and whose key tag is 2642. 4. The NSEC Resource Record The NSEC resource record lists two separate things: the next owner - name (in the canonical ordering of the zone) which contains + name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset, 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]. + types present at the NSEC RR's owner name [RFC3845]. The complete + set of NSEC RRs in a zone indicates 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 [RFC4035]. 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 signed zone. - - See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone - signer determines precisely which NSEC RRs it needs to include in a + This is a change to the traditional DNS specification [RFC1034], + which 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 does a CNAME resource record in a signed zone. + See [RFC4035] for discussion of how a zone signer determines + precisely which NSEC RRs it has to include in a zone. + The type value for the NSEC RR is 47. The NSEC RR is class independent. @@ -758,7 +660,23 @@ Internet-Draft DNSSEC Resource Records October 2004 The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]). -4.1 NSEC RDATA Wire Format + + + + + + + + + + + +Arends, et al. Standards Track [Page 12] + +RFC 4034 DNSSEC Resource Records March 2005 + + +4.1. NSEC RDATA Wire Format The RDATA of the NSEC RR is as shown below: @@ -770,21 +688,12 @@ Internet-Draft DNSSEC Resource Records October 2004 / Type Bit Maps / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -4.1.1 The Next Domain Name Field +4.1.1. The Next Domain Name Field The Next Domain field contains the next owner name (in the canonical - ordering of the zone) which has authoritative data or contains a + ordering of the zone) that has authoritative data or contains a delegation point NS RRset; see Section 6.1 for an explanation of canonical ordering. The value of the Next Domain Name field in the - - - -Arends, et al. Expires April 10, 2005 [Page 14] - -Internet-Draft DNSSEC Resource Records October 2004 - - last NSEC record in the zone is the name of the zone apex (the owner name of the zone's SOA RR). This indicates that the owner name of the NSEC RR is the last name in the canonical ordering of the zone. @@ -792,13 +701,14 @@ Internet-Draft DNSSEC Resource Records October 2004 A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR. - 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. + Owner names of RRsets for which the given zone is not authoritative + (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 +4.1.2. The Type Bit Maps Field - The Type Bit Maps field identifies the RRset types which exist at the + The Type Bit Maps field identifies the RRset types that exist at the NSEC RR's owner name. The RR type space is split into 256 window blocks, each representing @@ -815,32 +725,30 @@ Internet-Draft DNSSEC Resource Records October 2004 where "|" denotes concatenation. + + +Arends, et al. Standards Track [Page 13] + +RFC 4034 DNSSEC Resource Records March 2005 + + 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, - it indicates that an RRset of that type is present for the NSEC RR's - owner name. If a bit is clear, it indicates that no RRset of that - type is present for the NSEC RR's owner name. + corresponds to RR type 257, and bit 2 to RR type 258. If a bit is + set, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is clear, it indicates that no RRset of + that type is present for the NSEC RR's owner name. - Bits representing pseudo-types MUST be clear, since they do not - appear in zone data. If encountered, they MUST be ignored upon - reading. + Bits representing pseudo-types MUST be clear, as they do not appear + in zone data. If encountered, they MUST be ignored upon being read. 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 April 10, 2005 [Page 15] - -Internet-Draft DNSSEC Resource Records October 2004 - - interpreted as zero octets. The bitmap for the NSEC RR at a delegation point requires special @@ -852,16 +760,16 @@ Internet-Draft DNSSEC Resource Records October 2004 A zone MUST NOT include an NSEC RR for any domain name that only holds glue records. -4.1.3 Inclusion of Wildcard Names in NSEC RDATA +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. + owner name for the purposes of generating NSEC RRs. Wildcard owner + names appear in the Next Domain Name field without any wildcard + expansion. [RFC4035] describes the impact of wildcards on + authenticated denial of existence. -4.2 The NSEC RR Presentation Format +4.2. The NSEC RR Presentation Format The presentation format of the RDATA portion is as follows: @@ -869,34 +777,34 @@ Internet-Draft DNSSEC Resource Records October 2004 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. + described in [RFC3597], Section 5, MUST be used. -4.3 NSEC RR Example + + + + +Arends, et al. Standards Track [Page 14] + +RFC 4034 DNSSEC Resource Records March 2005 + + +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. 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. + (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 that 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: - - - - -Arends, et al. Expires April 10, 2005 [Page 16] - -Internet-Draft DNSSEC Resource Records October 2004 - - 0x04 'h' 'o' 's' 't' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00 @@ -907,51 +815,9 @@ Internet-Draft DNSSEC Resource Records October 2004 0x00 0x00 0x00 0x00 0x20 Assuming that the validator 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 April 10, 2005 [Page 17] - -Internet-Draft DNSSEC Resource Records October 2004 - + could be used to prove that beta.example.com does not exist, or to + prove that there is no AAAA record associated with alfa.example.com. + Authenticated denial of existence is discussed in [RFC4035]. 5. The DS Resource Record @@ -963,18 +829,26 @@ Internet-Draft DNSSEC Resource Records October 2004 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]. + [RFC4035]. 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 + + + +Arends, et al. Standards Track [Page 15] + +RFC 4034 DNSSEC Resource Records March 2005 + + "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 + 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]. + [RFC4035]. The type number for the DS record is 43. @@ -982,11 +856,10 @@ Internet-Draft DNSSEC Resource Records October 2004 The DS RR has no special TTL requirements. -5.1 DS RDATA Wire Format +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. + The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet + Algorithm field, a 1 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 @@ -998,18 +871,7 @@ Internet-Draft DNSSEC Resource Records October 2004 / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - -Arends, et al. Expires April 10, 2005 [Page 18] - -Internet-Draft DNSSEC Resource Records October 2004 - - -5.1.1 The Key Tag Field +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, in network byte order. @@ -1017,7 +879,7 @@ Internet-Draft DNSSEC Resource Records October 2004 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 +5.1.2. The Algorithm Field The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record. @@ -1026,13 +888,25 @@ Internet-Draft DNSSEC Resource Records October 2004 number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm number types. -5.1.3 The Digest Type Field + + + + + + + +Arends, et al. Standards Track [Page 16] + +RFC 4034 DNSSEC Resource Records March 2005 + + +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 +5.1.4. The Digest Field The DS record refers to a DNSKEY RR by including a digest of that DNSKEY RR. @@ -1047,29 +921,20 @@ Internet-Draft DNSSEC Resource Records October 2004 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. + DNSKEY RR size. As of the time of this writing, the only defined + digest algorithm is SHA-1, which produces a 20 octet digest. -5.2 Processing of DS RRs When Validating Responses +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 April 10, 2005 [Page 19] - -Internet-Draft DNSSEC Resource Records October 2004 - - have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC - zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in - the validation process. + zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be + used in the validation process. -5.3 The DS RR Presentation Format +5.3. The DS RR Presentation Format The presentation format of the RDATA portion is as follows: @@ -1081,11 +946,21 @@ Internet-Draft DNSSEC Resource Records October 2004 The Digest Type field MUST be represented as an unsigned decimal integer. + + + + + +Arends, et al. Standards Track [Page 17] + +RFC 4034 DNSSEC Resource Records March 2005 + + 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 +5.4. DS RR Example The following example shows a DNSKEY RR and its corresponding DS RR. @@ -1102,7 +977,6 @@ Internet-Draft DNSSEC Resource Records October 2004 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 @@ -1110,33 +984,34 @@ Internet-Draft DNSSEC Resource Records October 2004 algorithm used to construct the digest, and the rest of the RDATA text is the digest in hexadecimal. - - - - - - -Arends, et al. Expires April 10, 2005 [Page 20] - -Internet-Draft DNSSEC Resource Records October 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. + within an RRset are required in order to construct and verify RRSIG + RRs. -6.1 Canonical DNS Name Order +6.1. Canonical DNS Name Order - For purposes of DNS security, owner names are ordered by treating + For the 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 + absence of a octet sorts before a zero value octet, and uppercase + US-ASCII letters are treated as if they were lowercase US-ASCII letters. + + + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4034 DNSSEC Resource Records March 2005 + + 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, @@ -1146,8 +1021,8 @@ Internet-Draft DNSSEC Resource Records October 2004 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. + by names ending "z.example". The names within each level are sorted + in the same way. example a.example @@ -1159,263 +1034,171 @@ Internet-Draft DNSSEC Resource Records October 2004 *.z.example \200.z.example +6.2. Canonical RR Form -6.2 Canonical RR Form + For the purposes of DNS security, the canonical form of an RR is the + wire format of the RR where: - 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 + 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 + + 2. all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters; - - - -Arends, et al. Expires April 10, 2005 [Page 21] - -Internet-Draft DNSSEC Resource Records October 2004 - - - 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + 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 + 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 + + 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 + + 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. + + + +Arends, et al. Standards Track [Page 19] + +RFC 4034 DNSSEC Resource Records March 2005 + + +6.3. Canonical RR Ordering within an RRset + + For the 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 + in which 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 when - putting the RRset in canonical form, 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 April 10, 2005 [Page 22] - -Internet-Draft DNSSEC Resource Records October 2004 - + putting the RRset in canonical form, it 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), it MUST remove all but one of the duplicate RR(s) for the + purposes of calculating the canonical form of the RRset. 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. + This document introduces no new IANA considerations, as 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 that are (or once were) related to DNSSEC. - Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA - considerations. + Please refer to [RFC4035] 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. [RFC3755] assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. - [RFC3755] 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]. + [RFC3755] 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 to 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 + for DNSSEC Resource Record Algorithm field numbers and assigned values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] 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 + transaction security (see [RFC2931]), or both. Values 6-251 are available for assignment by IETF standards action ([RFC3755]). 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. + Numbers entries at the time of this writing and their status for + use in DNSSEC. - [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and + + + +Arends, et al. Standards Track [Page 20] + +RFC 4034 DNSSEC Resource Records March 2005 + + + [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 values other than 3 + Protocol Values, but [RFC3445] reassigned all 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 + closed, and all KEY and DNSKEY records are required to have a Protocol Octet value of 3. Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, this registry only contains assignments for bit 7 (the ZONE bit) - and bit 15 (the Secure Entry Point flag (SEP) bit, see [RFC3757]). - As also stated in [RFC3755], bits 0-6 and 8-14 are available for + and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). + As stated in [RFC3755], bits 0-6 and 8-14 are available for assignment by IETF Standards Action. - - -Arends, et al. Expires April 10, 2005 [Page 23] - -Internet-Draft DNSSEC Resource Records October 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 + 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. + security considerations. Please see [RFC4033] and [RFC4035] 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 + The DS record points to a DNSKEY RR by 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. + probability of constructing 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 that 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 uses only the key tag to select a DNSKEY RR + An implementation that uses only the key tag to select a DNSKEY RR might select the wrong public key in some circumstances. Please see Appendix B for further details. + + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4034 DNSSEC Resource Records March 2005 + + The table of algorithms in Appendix A and the key tag calculation algorithms in Appendix B include the RSA/MD5 algorithm for completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as explained in [RFC3110]. - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 24] - -Internet-Draft DNSSEC Resource Records October 2004 - - -9. Acknowledgments +9. 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 April 10, 2005 [Page 25] - -Internet-Draft DNSSEC Resource Records October 2004 - + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. 10. References -10.1 Normative References - - [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-10 (work in progress), May - 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-06 (work in - progress), May 2004. +10.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. @@ -1429,36 +1212,30 @@ Internet-Draft DNSSEC Resource Records October 2004 [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. - [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. + [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2536, March 1999. - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. - [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 + [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)", RFC 3110, May 2001. -Arends, et al. Expires April 10, 2005 [Page 26] + + +Arends, et al. Standards Track [Page 22] -Internet-Draft DNSSEC Resource Records October 2004 +RFC 4034 DNSSEC Resource Records March 2005 - 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. @@ -1472,101 +1249,47 @@ Internet-Draft DNSSEC Resource Records October 2004 (RR)", RFC 3658, December 2003. [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", RFC 3755, April 2004. + Signer (DS)", RFC 3755, May 2004. - [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", RFC 3757, April 2004. + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. -10.2 Informative References + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. - [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name - System (DNS)", RFC 2537, March 1999. +10.2. Informative References - [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain + Name System (DNS)", RFC 2537, March 1999. + + [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004. -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl -Arends, et al. Expires April 10, 2005 [Page 27] + + +Arends, et al. Standards Track [Page 23] -Internet-Draft DNSSEC Resource Records October 2004 - - - 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 - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 28] - -Internet-Draft DNSSEC Resource Records October 2004 +RFC 4034 DNSSEC Resource Records March 2005 Appendix A. DNSSEC Algorithm and Digest Types @@ -1579,22 +1302,22 @@ Appendix A. DNSSEC Algorithm and Digest Types 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. + warrant them. A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms. -A.1 DNSSEC Algorithm Types +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 + The DNSKEY, RRSIG, and DS RRs use an 8-bit number 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] + SIG(0) and KEY RRs, as described in [RFC2931]. Zone Value Algorithm [Mnemonic] Signing References Status @@ -1612,34 +1335,39 @@ A.1 DNSSEC Algorithm Types 6 - 251 Available for assignment by IETF Standards Action. -A.1.1 Private Algorithm Types + + + + + + + + +Arends, et al. Standards Track [Page 24] + +RFC 4034 DNSSEC Resource Records March 2005 + + +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 April 10, 2005 [Page 29] - -Internet-Draft DNSSEC Resource Records October 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. + 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 + 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.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 @@ -1650,37 +1378,6 @@ A.2 DNSSEC Digest Types 1 SHA-1 MANDATORY 2-255 Unassigned - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 30] - -Internet-Draft DNSSEC Resource Records October 2004 - - Appendix B. Key Tag Calculation The Key Tag field in the RRSIG and DS resource record types provides @@ -1698,15 +1395,24 @@ Appendix B. Key Tag Calculation it does not uniquely identify a DNSKEY record. Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR. + + + + +Arends, et al. Standards Track [Page 25] + +RFC 4034 DNSSEC Resource Records March 2005 + + 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. + 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 + 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 @@ -1724,19 +1430,6 @@ Appendix B. Key Tag Calculation format of the RDATA portion of the DNSKEY RR. The code is written for clarity, not efficiency. - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 31] - -Internet-Draft DNSSEC Resource Records October 2004 - - /* * Assumes that int is at least 16 bits. * First octet of the key tag is the most significant 8 bits of the @@ -1761,9 +1454,15 @@ Internet-Draft DNSSEC Resource Records October 2004 } -B.1 Key Tag for Algorithm 1 (RSA/MD5) - The key tag for algorithm 1 (RSA/MD5) is defined differently than the +Arends, et al. Standards Track [Page 26] + +RFC 4034 DNSSEC Resource Records March 2005 + + +B.1. Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently from 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 @@ -1788,12 +1487,108 @@ B.1 Key Tag for Algorithm 1 (RSA/MD5) -Arends, et al. Expires April 10, 2005 [Page 32] + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 27] -Internet-Draft DNSSEC Resource Records October 2004 +RFC 4034 DNSSEC Resource Records March 2005 -Intellectual Property Statement +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC 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 + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.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. Standards Track [Page 28] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -1814,29 +1609,10 @@ Intellectual Property Statement The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment +Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. @@ -1844,6 +1620,8 @@ Acknowledgment -Arends, et al. Expires April 10, 2005 [Page 33] - + + +Arends, et al. Standards Track [Page 29] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-09.txt b/doc/rfc/rfc4035.txt similarity index 66% rename from doc/draft/draft-ietf-dnsext-dnssec-protocol-09.txt rename to doc/rfc/rfc4035.txt index 416f6c9f04..b701cd2f23 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-09.txt +++ b/doc/rfc/rfc4035.txt @@ -1,243 +1,213 @@ -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: April 10, 2005 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI + + + + +Network Working Group R. Arends +Request for Comments: 4035 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University S. Rose NIST - October 10, 2004 + March 2005 Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-09 -Status of this Memo +Status of This Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 10, 2005. + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). Abstract - - - -Arends, et al. Expires April 10, 2005 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - - This document is part of a family of documents which describe the DNS + This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of new resource records and protocol modifications which + collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for - serving and resolving using DNSSEC. These techniques allow a + serving and resolving by 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. + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5 - 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 - 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8 - 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 - 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10 - 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 - 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 - 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 - 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 - 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 - 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 - 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 - 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 - 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 - 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 Configured Trust Anchors . . . . . . . . . . . . . . . . . 22 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22 - 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 23 - 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 23 - 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 24 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . . 4 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5 + 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5 + 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6 + 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7 + 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7 + 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8 + 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9 + 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10 + 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11 + 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11 + 3.1.4. Including DS RRs in a Response . . . . . . . . . 14 + 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15 + 3.1.6. The AD and CD Bits in an Authoritative Response. 16 + 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17 + 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17 + 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17 + 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18 + 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19 + 4.2. Signature Verification Support . . . . . . . . . . . . . 19 + 4.3. Determining Security Status of Data . . . . . . . . . . 20 + 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21 + 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21 + 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22 + 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22 + 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23 + 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23 + 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24 + 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24 + 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 + 5.1. Special Considerations for Islands of Security . . . . . 26 + 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26 + 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28 + 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28 + 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29 + 5.3.3. Checking the Signature . . . . . . . . . . . . . 31 + 5.3.4. Authenticating a Wildcard Expanded RRset + Positive Response. . . . . . . . . . . . . . . . 32 -Arends, et al. Expires April 10, 2005 [Page 2] +Arends, et al. Standards Track [Page 2] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 - 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 24 - 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24 - 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24 - 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 25 - 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 . . . . . . . . . . . . 29 - 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 Resolver Behavior When Signatures Do Not Validate . . . . 33 - 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 33 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 - 9.2 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 . . . . . . . . . . . . . . . . . . . . 51 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 52 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 53 - C. Authentication Examples . . . . . . . . . . . . . . . . . . . 55 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 55 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 55 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 56 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 56 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 56 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 56 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 57 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 57 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 57 - Intellectual Property and Copyright Statements . . . . . . . . 58 - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - + 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32 + 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33 + 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 9.2. Informative References . . . . . . . . . . . . . . . . . 35 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41 + B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41 + B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43 + B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44 + B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44 + B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45 + B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46 + B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47 + B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49 + C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49 + C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49 + C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50 + C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50 + C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50 + C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51 + C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51 + C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51 + C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications which add data origin + records and protocol modifications that 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 + name server behavior necessary for handling signed zones. Section 4 + describes the behavior of entities that include security-aware resolver functions. Finally, Section 5 defines how to use DNSSEC RRs to authenticate a response. -1.1 Background and Related Documents - This document is part of a family of documents that define DNSSEC, - which should be read together as a set. - [I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and - definitions of common terms; the reader is assumed to be familiar - with this document. [I-D.ietf-dnsext-dnssec-intro] also contains a - list of other documents updated by and obsoleted by this document - set. - [I-D.ietf-dnsext-dnssec-records] defines the DNSSEC resource records. + + + +Arends, et al. Standards Track [Page 3] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +1.1. Background and Related Documents + + This document is part of a family of documents defining DNSSEC that + should be read together as a set. + + [RFC4033] contains an introduction to DNSSEC and definitions of + common terms; the reader is assumed to be familiar with this + document. [RFC4033] also contains a list of other documents updated + by and obsoleted by this document set. + + [RFC4034] defines the DNSSEC resource records. The reader is also assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that - update them, particularly [RFC2181] and [RFC2308]. + update them; particularly, [RFC2181] and [RFC2308]. This document defines the DNSSEC protocol operations. -1.2 Reserved Words +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]. - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. 2. Zone Signing DNSSEC introduces the concept of signed zones. A signed zone includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), - Next Secure (NSEC) and (optionally) Delegation Signer (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. + Next Secure (NSEC), and (optionally) Delegation Signer (DS) records + according to the rules specified in Sections 2.1, 2.2, 2.3, and 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. + and NSEC RRs to appear at the same owner name as does a CNAME RR. DNSSEC specifies the placement of two new RR types, NSEC and DS, which can be placed at the parental side of a zone cut (that is, at a @@ -245,61 +215,81 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 against putting data in the parent zone at a zone cut. Section 2.6 describes this change. -2.1 Including DNSKEY RRs in a Zone + + + + + + + + +Arends, et al. Standards Track [Page 4] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +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 in a zone, the zone SHOULD include a zone DNSKEY RR containing the corresponding public key. A zone key DNSKEY RR MUST - have the Zone Key bit of the flags RDATA field set -- 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. + have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 + of [RFC4034]). 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 administrator intends a signed zone to be usable other than as an island of security, the zone apex MUST contain at least one DNSKEY RR to act as a secure entry point into the zone. This secure entry point could then be used as the target of a secure delegation via a corresponding DS RR in the parent zone (see - [I-D.ietf-dnsext-dnssec-records]). + [RFC4034]). -2.2 Including RRSIG RRs in a Zone +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; + one RRSIG record that meets 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. -Arends, et al. Expires April 10, 2005 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications October 2004 + 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 RR's TTL is equal to the TTL of the RRset; o The RRSIG Labels field is equal to the number of labels in the RRset owner name, not counting the null root label and not - counting the leftmost label if it is a wildcard; + 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 + containing the RRset. + 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. Note that, because RRSIG RRs - are closely tied to the RRsets whose signatures they contain, RRSIG - RRs, unlike all other DNS RR types, do not form RRsets. In - particular, the TTL values among RRSIG RRs with a common owner name - do not follow the RRset rules described in [RFC2181]. + described in [RFC4034]. An RRset MAY have multiple RRSIG RRs + associated with it. Note that as RRSIG RRs are closely tied to the + RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS - 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 + + +Arends, et al. Standards Track [Page 5] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RR types, do not form RRsets. In particular, the TTL values among + RRSIG RRs with a common owner name do not follow the RRset rules + described in [RFC2181]. + + An RRSIG RR itself MUST NOT be signed, as 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 @@ -313,30 +303,22 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). -2.3 Including NSEC RRs in a Zone +2.3. Including NSEC RRs in a Zone - Each owner name in the zone which has authoritative data or a + Each owner name in the zone that has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. The format of NSEC RRs and the process for constructing the NSEC RR for a - given name is described in [I-D.ietf-dnsext-dnssec-records]. + given name is described in [RFC4034]. 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 main + MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not + the owner name of any RRset before the zone was signed. The main reasons for this are a desire for namespace consistency between signed and unsigned versions of the same zone and a desire to reduce - - - -Arends, et al. Expires April 10, 2005 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - the risk of response inconsistency in security oblivious recursive name servers. @@ -350,12 +332,20 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 + + + +Arends, et al. Standards Track [Page 6] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + 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 + RRsets. Note, however, that this distinction is for the most part + visible only during the zone signing process, as NSEC RRsets are + authoritative data and are therefore signed. Thus, any owner name + that has an NSEC RRset will have RRSIG RRs as well in the signed zone. The bitmap for the NSEC RR at a delegation point requires special @@ -364,39 +354,31 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear. -2.4 Including DS RRs in a 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 + 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 + A DS RR SHOULD point to a DNSKEY RR that is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. DS RRs which fail to meet these - conditions are not useful for validation, but since the DS RR and its - corresponding DNSKEY RR are in different zones, and since the DNS is - only loosely consistent, temporary mismatches can occur. + by the corresponding private key. DS RRs that fail to meet these + conditions are not useful for validation, but because the DS RR and + its corresponding DNSKEY RR are in different zones, and because the + DNS is only loosely consistent, temporary mismatches can occur. The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset (that is, 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 - - - -Arends, et al. Expires April 10, 2005 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - child and parent zones. This communication is an operational matter not covered by this document. -2.5 Changes to the CNAME Resource Record. +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 @@ -406,19 +388,27 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 + + + +Arends, et al. Standards Track [Page 7] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + 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. -2.6 DNSSEC RR Types Appearing at Zone Cuts. +2.6. DNSSEC RR Types Appearing at Zone Cuts DNSSEC introduced two new RR types that are unusual in that they can appear at the parental side of a zone cut. At the parental side of a zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at the owner name. A DS RR could also be present if the zone being - delegated is signed and wishes to have a chain of authentication to + delegated is signed and seeks to have a chain of authentication to the parent zone. This is an exception to the original DNS - specification ([RFC1034]) which states that only NS RRsets could + specification ([RFC1034]), which states that only NS RRsets could appear at the parental side of a zone cut. This specification updates the original DNS specification to allow @@ -426,29 +416,10 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 are authoritative for the parent when they appear at the parent side of a zone cut. -2.7 Example of a Secure Zone +2.7. Example of a Secure Zone Appendix A shows a complete example of a small signed zone. - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - 3. Serving This section describes the behavior of entities that include @@ -459,12 +430,12 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 + In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" 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. Since IPv6 + octets, and SHOULD support a message size of 4000 octets. As IPv6 packets can only be fragmented by the source host, a security aware name server SHOULD take steps to ensure that UDP datagrams it transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 @@ -472,66 +443,80 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 and [RFC3226] for further discussion of packet size and fragmentation issues. - A security-aware name server which receives a DNS query that does not + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 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 clear 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. + treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and + MUST NOT perform any of the additional processing described below. + Because 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. Security aware name servers that receive explicit queries for - security RR types which match the content of more than one zone that + security RR types that match the content of more than one zone that it serves (for example, NSEC and RRSIG RRs above and below a delegation point where the server is authoritative for both zones) - should behave self-consistently. The name server MAY return one of - the following: - o The above-delegation RRsets - o The below-delegation RRsets - o Both above and below-delegation RRsets - o Empty answer section (no records) - o Some other response - o An error - As long as the response is always consistent for each query to the - name server. + should behave self-consistently. As long as the response is always + consistent for each query to the name server, the name server MAY + return one of the following: + + o The above-delegation RRsets. + o The below-delegation RRsets. + o Both above and below-delegation RRsets. + o Empty answer section (no records). + o Some other response. + o An error. DNSSEC allocates two new bits in the DNS message header: the CD (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit - - - -Arends, et al. Expires April 10, 2005 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - 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.9 for details - on the behavior of these bits. + ignore the setting of the AD bit in queries. See Sections 3.1.6, + 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. - A security aware name server which synthesizes CNAME RRs from DNAME + A security aware name server that synthesizes CNAME RRs from DNAME RRs as described in [RFC2672] SHOULD NOT generate signatures for the synthesized CNAME RRs. -3.1 Authoritative Name Servers +3.1. Authoritative Name Servers Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name server for a signed zone MUST include additional RRSIG, NSEC, and DS - RRs according to the following rules: + 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; + included in the response according to the rules in Section 3.1.1. + + + + + + + +Arends, et al. Standards Track [Page 9] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + 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; + to the rules in Section 3.1.3. + 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. - These rules only apply to responses the semantics of which convey + These rules only apply to responses where the semantics convey information about the presence or absence of resource records. That is, these rules are not intended to rule out responses such as RCODE 4 ("Not Implemented") or RCODE 5 ("Refused"). @@ -539,7 +524,7 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 +3.1.1. Including RRSIG RRs in a Response When responding to a query that has the DO bit set, a security-aware authoritative name server SHOULD attempt to send RRSIG RRs that a @@ -547,25 +532,19 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 response. A name server SHOULD make every attempt to keep the RRset and its associated RRSIG(s) together in a 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 + that may have to be included. If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit. - - - -Arends, et al. Expires April 10, 2005 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - 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 + RRsets that may have 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 @@ -573,14 +552,26 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 dropping the RRSIG RRs. If this happens, 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 + + + + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.2. Including DNSKEY RRs in a Response When responding to a query that has the DO bit set 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. + DNSKEY RRset and associated RRSIG RRs have lower priority than does + 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 @@ -588,13 +579,13 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 NOT set the TC bit solely because these RRs didn't fit (see Section 3.1.1). -3.1.3 Including NSEC RRs In a Response +3.1.3. Including NSEC RRs in a Response When responding to a query that has the DO bit set, 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 , + No Data: The zone contains RRsets that exactly match but does not contain any RRsets that exactly match . @@ -606,25 +597,30 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 - - - -Arends, et al. Expires April 10, 2005 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - - expansion. + match and 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. + returning is correct given the data in the zone. -3.1.3.1 Including NSEC RRs: No Data Response + + + + + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +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 @@ -635,22 +631,24 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 + to this query, and a single signed NSEC RR suffices to prove that the requested RR type does not exist. -3.1.3.2 Including NSEC RRs: Name Error Response +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: + o An NSEC RR proving that there is no exact match for ; and + SCLASS>. + 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 + In some cases, a single NSEC RR may prove both of these points. If + it does, 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 @@ -662,45 +660,47 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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). + that is not the owner name for any RRset but that 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 that exactly match but does contain an RRset that matches + via wildcard name expansion, the name server MUST include the - -Arends, et al. Expires April 10, 2005 [Page 12] +Arends, et al. Standards Track [Page 12] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 -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 + 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 +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 - would have been a closer match for . + contain an exact match for , and although the zone + does contain RRsets that match via wildcard + expansion, none of those RRsets matches STYPE. The name server MUST + include the following NSEC RRs in the Authority section, along with + their associated RRSIG RRs: - 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 + o An NSEC RR proving that there are no RRsets matching STYPE at the + wildcard owner name that matched via wildcard + expansion. + + o An NSEC RR proving that there are no RRsets in the zone that would + have been a closer match for . + + In some cases, a single NSEC RR may prove both of these points. If + it does, 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 @@ -710,48 +710,48 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 +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 no RRsets matching a particular SNAME exist. + security-aware authoritative name server has to locate an NSEC RR + that proves that no RRsets matching a particular SNAME 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 RRsets matching SNAME. The algorithm below is - written for clarity, not efficiency. + the name server is authoritative for the zone that would have held + the non-existent RRsets matching SNAME. The algorithm below is + written for clarity, not for efficiency. - - - -Arends, et al. Expires April 10, 2005 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - - To find the NSEC which proves that no RRsets matching name N exist in - the zone Z which would have held them, construct sequence S + To find the NSEC that proves that no RRsets matching name N exist in + the zone Z that would have held them, construct a sequence, S, consisting of the owner names of every RRset in Z, sorted into - canonical order ([I-D.ietf-dnsext-dnssec-records]), with no duplicate - names. Find the name M which would have immediately preceded N in S - if any RRsets with owner name N had existed. M is the owner name of - the NSEC RR which proves that no RRsets exist with owner name N. - 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 + + +Arends, et al. Standards Track [Page 13] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + canonical order ([RFC4034]), with no duplicate names. Find the name + M that would have immediately preceded N in S if any RRsets with + owner name N had existed. M is the owner name of the NSEC RR that + proves that no RRsets exist with owner name N. + + The algorithm for finding the NSEC RR that 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 no RRsets exist with the applicable wildcard name is - precisely the same as the algorithm for finding the NSEC RR which - proves that RRsets with any other owner name do 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 + precisely the same as the algorithm for finding the NSEC RR that + proves that RRsets with any other owner name do not exist. The part + that's missing is a method of determining the name of the non- + existent 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 +3.1.4. Including DS RRs in a Response - When responding to a query which has the DO bit set, a security-aware + When responding to a query that has the DO bit set, a security-aware authoritative name server returning a referral includes DNSSEC data along with the NS RRset. @@ -760,35 +760,34 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 Authority section along with the NS RRset. 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 + MUST return both the NSEC RR that 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. + 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 +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 - - - -Arends, et al. Expires April 10, 2005 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - - 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 + rules for both name servers and resolvers, as 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. + + +Arends, et al. Standards Track [Page 14] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + 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 @@ -801,11 +800,15 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 - o the name server does not offer recursion. + + o The name server has received a query for the DS RRset at a zone + cut. + + o The name server is authoritative for the child zone. + + o The name server is not authoritative for the parent zone. + + 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 @@ -813,13 +816,13 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 + If all 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 +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 @@ -829,54 +832,54 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 that chooses to perform + zone transfer if the zone fails to meet 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 that -Arends, et al. Expires April 10, 2005 [Page 15] +Arends, et al. Standards Track [Page 15] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 - its own zone validation MUST NOT selectively reject some RRs and - accept others. + 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 + 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 + 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 in zone transfers - of the parent zone, while the NSEC at the zone apex of the child zone - MUST be included in zone transfers of the child zone. + other, as the NSEC RR in the child zone's apex will always indicate + the presence of the child zone's SOA RR whereas 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 in zone transfers of + the parent zone, and the NSEC at the zone apex of the child zone 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. - Parental and child RRSIG RRs at a zone cut will never be identical to - each other, since the Signer's Name field of an RRSIG RR in the child - zone's apex will indicate a DNSKEY RR in the child zone's apex while - the same field of a parental RRSIG RR at the zone cut will indicate a + 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, and the RRSIG for any RRset in the + child zone's apex will be authoritative in the child zone. Parental + and child RRSIG RRs at a zone cut will never be identical to each + other, as the Signer's Name field of an RRSIG RR in the child zone's + apex will indicate a DNSKEY RR in the child zone's apex whereas the + same field of a parental RRSIG RR at the zone cut will indicate a DNSKEY RR in the parent zone's apex. 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 +3.1.6. The AD and CD Bits in an Authoritative Response The CD and AD bits are designed for use in communication between security-aware resolvers and security-aware recursive name servers. @@ -884,55 +887,57 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 security-aware authoritative name servers. A security-aware name server does not perform signature validation - for authoritative data during query processing even when the CD bit + for authoritative data during query processing, even when the CD bit is clear. A security-aware name server SHOULD clear the CD bit when composing an authoritative response. - A security-aware name server MUST NOT set the AD bit in a response -Arends, et al. Expires April 10, 2005 [Page 16] + +Arends, et al. Standards Track [Page 16] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 + 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. + zone to be authentic without further validation. However, 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 + A security-aware name server that 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 +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. + As explained in [RFC4033], a security-aware recursive name server is + an entity that 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 that implements the + security-aware name server role and the code that 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. + caching that would apply to any security-aware resolver. -3.2.1 The DO bit +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 + MUST strip any authenticating DNSSEC RRs from the response but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested. -3.2.2 The CD bit +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 @@ -943,30 +948,30 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 The name server side of a security-aware recursive name server MUST pass the state 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 -Arends, et al. Expires April 10, 2005 [Page 17] +Arends, et al. Standards Track [Page 17] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 - name server side. If the CD bit is set, 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 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 + of an initiating query, so that the resolver side will know whether + it is required to verify the response data it returns to the name + server side. If the CD bit is set, 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, 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 + name server side receives a query that matches an entry in the resolver side's BAD cache, the name server side's response depends on the state 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 @@ -974,19 +979,19 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 (server failure). 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 the resolver side of - a security-aware recursive name server to perform such checks. - Several of the possible reasons why signature validation might fail - involve conditions which may not apply equally to the recursive name - server and the client which invoked it: for example, the recursive - name server's clock may be set incorrectly, or the client may have - knowledge of a relevant island of security which the recursive name - server does not share. In such cases, "protecting" a client which is + that are capable of performing their own signature verification + checks while protecting clients that depend on the resolver side of a + security-aware recursive name server to perform such checks. Several + of the possible reasons why signature validation might fail involve + conditions that may not apply equally to the recursive name server + and the client that invoked it. For example, the recursive name + server's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security that the recursive name + server does not share. In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client. -3.2.3 The AD bit +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 @@ -996,75 +1001,25 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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. - However, for backwards compatibility, a recursive name server MAY set + However, for backward compatibility, a recursive name server MAY set the AD bit when a response includes unsigned CNAME RRs if those CNAME + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + RRs demonstrably could have been synthesized from an authentic DNAME - RR which is also included in the response according to the synthesis + RR that is also included in the response according to the synthesis rules described in [RFC2672]. - - -Arends, et al. Expires April 10, 2005 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - -3.3 Example DNSSEC Responses +3.3. Example DNSSEC Responses See Appendix B for example response packets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - 4. Resolving This section describes the behavior of entities that include @@ -1074,53 +1029,57 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 specific to security-aware recursive name servers are described in Section 3.2. -4.1 EDNS Support +4.1. EDNS Support A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-RR with the DO ([RFC3225]) bit set 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 message size it's willing to accept using the "sender's - UDP payload size" field in the EDNS OPT pseudo-RR. A security-aware - resolver's IP layer MUST handle fragmented UDP packets correctly - regardless of whether any such fragmented packets were received via - IPv4 or IPv6. Please see [RFC1122], [RFC2460] and [RFC3226] for - discussion of these requirements. + use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR + to advertise the message size that it is willing to accept. A + security-aware resolver's IP layer MUST handle fragmented UDP packets + correctly regardless of whether any such fragmented packets were + received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and + [RFC3226] for discussion of these requirements. -4.2 Signature Verification Support +4.2. Signature Verification Support A security-aware resolver MUST support the signature verification - mechanisms described in Section 5, and SHOULD apply them to every - received response except when: - o The security-aware resolver is part of a security-aware recursive + mechanisms described in Section 5 and SHOULD 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 + + o the response is the result of a query generated directly via some + form of application interface that instructed the security-aware resolver not to perform validation for this query; or - o Validation for this query has been disabled by local policy. + + o validation for this query has been disabled by local policy. + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + A security-aware resolver's support for signature verification MUST include support for verification of wildcard owner names. - Security aware resolvers MAY query for missing security RRs in an + Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries. - When attempting to retrieve missing NSEC RRs which reside on the + When attempting to retrieve missing NSEC RRs that reside on the parental side at a zone cut, a security-aware iterative-mode resolver - - - -Arends, et al. Expires April 10, 2005 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - MUST query the name servers for the parent zone, not the child zone. When attempting to retrieve a missing DS, a security-aware @@ -1132,22 +1091,22 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 + RRset by that name. If no NS RRset is present at that name, the resolver then strips off 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. -4.3 Determining Security Status of Data +4.3. Determining Security Status of Data - A security-aware resolver MUST be able to determine whether or not it - should expect a particular RRset to be signed. More precisely, a + A security-aware resolver MUST be able to determine whether it should + expect a particular RRset to be signed. More precisely, a security-aware resolver must be able to distinguish between four cases: Secure: 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. + RRset. In this case, the RRset should be signed and is subject to + signature validation, as described above. Insecure: 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 @@ -1156,31 +1115,33 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 RRset may or may not be signed, but the resolver will not be able to verify the signature. + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + Bogus: An RRset for which the resolver believes that it ought to be - able to establish a chain of trust but is unable to do so, either - due to signatures that for some reason fail to validate or due to - missing data which the relevant DNSSEC RRs indicate should be - present. This case may indicate an attack, but may also indicate - a configuration error or some form of data corruption. + able to establish a chain of trust but for which it is unable to + do so, either due to signatures that for some reason fail to + validate or due to missing data that the relevant DNSSEC RRs + indicate should be present. This case may indicate an attack but + may also indicate a configuration error or some form of data + corruption. Indeterminate: 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. + determine whether the RRset should be signed, as 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. - - - -Arends, et al. Expires April 10, 2005 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - -4.4 Configured Trust Anchors +4.4. Configured Trust Anchors A security-aware resolver MUST be capable of being configured with at - least one trusted public key or DS RR, and SHOULD be capable of being + least one trusted public key or DS RR and SHOULD be capable of being configured with multiple trusted public keys or DS RRs. Since a security-aware resolver will not be able to validate signatures without such a configured trust anchor, the resolver SHOULD have some @@ -1189,11 +1150,11 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 storage (such as a disk drive) or some form of trusted local network configuration mechanism. - Note that trust anchors also covers key material that is updated in a + Note that trust anchors also cover key material that is updated in a secure manner. This secure manner could be through physical media, a - key exchange protocol, or some other out of band means. + key exchange protocol, or some other out-of-band means. -4.5 Response Caching +4.5. Response Caching A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset @@ -1209,31 +1170,36 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 authoritative data might have been changed (for example, via dynamic update). + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + There are two situations for which this is relevant: + 1. By using the RRSIG record, it is possible to deduce that an - answer was synthesized from a wildcard. A security aware + answer was synthesized from a wildcard. A security-aware recursive name server could store this wildcard data and use it to generate positive responses to queries other than the name for which the original answer was first received. + 2. NSEC RRs received to prove the non-existence of a name could be - reused by a security aware resolver to prove the non-existence of + reused by a security-aware resolver to prove the non-existence of any name in the name range it spans. In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or - synthesizing new data on their own. Resolvers which follow this + synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace. - - -Arends, et al. Expires April 10, 2005 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - -4.6 Handling of the CD and AD bits +4.6. Handling of the CD and AD Bits A security-aware resolver MAY set a query's CD bit in order to indicate that the resolver takes responsibility for performing @@ -1242,16 +1208,16 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 behavior of security-aware recursive name servers. A security-aware resolver MUST clear 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 - the response message. + messages to protect against buggy name servers that blindly copy + header bits that they do not understand from the query message to 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. + response unless the response was obtained by using a secure channel + or the resolver was specifically configured to regard the message + header bits without using a secure channel. -4.7 Caching BAD Data +4.7. Caching BAD Data While many validation errors will be transient, some are likely to be more persistent, such as those caused by administrative error @@ -1262,182 +1228,165 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions. + + + +Arends, et al. Standards Track [Page 22] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + Conceptually, caching such data is similar to negative caching ([RFC2308]), except that instead of caching a valid negative response, the resolver is caching the fact that a particular answer failed to validate. This document refers to a cache of data with invalid signatures as a "BAD cache". - Resolvers which implement a BAD cache MUST take steps to prevent the - cache from being useful as a denial-of-service attack amplifier. In - particular: - o Since RRsets which fail to validate do not have trustworthy TTLs, + Resolvers that implement a BAD cache MUST take steps to prevent the + cache from being useful as a denial-of-service attack amplifier, + particularly the following: + + o Since RRsets that fail to validate do not have trustworthy TTLs, the implementation MUST assign a TTL. This TTL SHOULD be small, in order to mitigate the effect of caching the results of an attack. + o In order to prevent caching of a transient validation failure (which might be the result of an attack), resolvers SHOULD track - queries that result in validation failures, and SHOULD only answer + queries that result in validation failures and SHOULD only answer from the BAD cache after the number of times that responses to queries for that particular have failed to validate exceeds a threshold value. - - -Arends, et al. Expires April 10, 2005 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - Resolvers MUST NOT return RRsets from the BAD cache unless the resolver is not required to validate the signatures of the RRsets in question under the rules given in Section 4.2 of this document. See Section 3.2.2 for discussion of how the responses returned by a security-aware recursive name server interact with a BAD cache. -4.8 Synthesized CNAMEs +4.8. Synthesized CNAMEs A validating security-aware resolver MUST treat the signature of a - valid signed DNAME RR as also covering unsigned CNAME RRs which could - have been synthesized from the DNAME RR as described in [RFC2672], at - least to the extent of not rejecting a response message solely + valid signed DNAME RR as also covering unsigned CNAME RRs that could + have been synthesized from the DNAME RR, as described in [RFC2672], + at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so. -4.9 Stub resolvers +4.9. 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.9.1 Handling of the DO Bit + + + + + + + +Arends, et al. Standards Track [Page 23] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +4.9.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. + data that the stub resolver hands back to the application that + invoked it, but is not required to do so. A non-validating stub + resolver that seeks to do this will need to set the DO bit in order + to 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. + A validating security-aware stub resolver MUST set the DO bit, + because otherwise it will not receive the DNSSEC RRs it needs to + perform signature validation. -4.9.2 Handling of the CD Bit +4.9.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 + bit when sending queries unless it is requested by the application + layer, as 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. + because 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 that would be + acceptable to the stub resolver's local policy. - - -Arends, et al. Expires April 10, 2005 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - -4.9.3 Handling of the AD Bit +4.9.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 + that 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 - recursive name server via a secure channel. + security-aware recursive name server. Therefore, there may be little + practical value in 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 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 + setting of the AD bit in response messages, as, by definition, the stub resolver performs its own signature validation regardless of the setting of the AD bit. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 25] +Arends, et al. Standards Track [Page 24] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 5. Authenticating DNS Responses - In order to use DNSSEC RRs for authentication, a security-aware - resolver requires configured knowledge of at least one authenticated - DNSKEY or DS RR. The process for obtaining and authenticating this - initial trust anchors 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 + To use DNSSEC RRs for authentication, a security-aware resolver + requires configured knowledge of at least one authenticated DNSKEY or + DS RR. The process for obtaining and authenticating this initial + trust anchor 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 to 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 trust anchors. 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, + RRset. To authenticate an apex DNSKEY RRset by using an initial key, the resolver MUST: - 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR has the Zone Key Flag - (DNSKEY RDATA bit 7) set. - 2. Verify that there is some RRSIG RR that covers the apex DNSKEY + + 1. verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA + bit 7) set; and + + 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 + Once the resolver has authenticated the apex DNSKEY RRset by using an + initial DNSKEY RR, delegations from that zone can be authenticated by + 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 configured 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 + RRsets in the zone once the resolver has authenticated a zone's apex + DNSKEY RRset. 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. @@ -1447,16 +1396,16 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 However, a security-aware resolver may still receive a response that lacks the appropriate DNSSEC RRs, whether due to configuration issues such as an upstream security-oblivious recursive name server that + + + +Arends, et al. Standards Track [Page 25] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + accidentally interferes with DNSSEC RRs or due to a deliberate attack in which an adversary forges a response, strips DNSSEC RRs from a - - - -Arends, et al. Expires April 10, 2005 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - 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 @@ -1468,27 +1417,27 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 +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 SHOULD switch to operating as - if the zones in the island of security are unsigned. + Islands of security (see [RFC4033]) 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 that the validator have some other means of obtaining an + initial authenticated zone key for the island. If a validator cannot + obtain such a key, it SHOULD switch to operating as if the zones in + the island of security are unsigned. 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 trust anchor for the authentication chain. -5.2 Authenticating Referrals +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 + zone's apex DNSKEY RRset and contains a cryptographic digest of the child zone's DNSKEY RR. Use of a strong cryptographic digest algorithm ensures that it is computationally infeasible for an adversary to generate a DNSKEY RR that matches the digest. Thus, @@ -1498,22 +1447,26 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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); + parent's apex DNSKEY RRset (see Section 5.3). + + + + + +Arends, et al. Standards Track [Page 26] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + o The Algorithm and Key Tag in the DS RR match the Algorithm field and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset and, when the DNSKEY RR's owner name and RDATA are hashed + RRset, and, when the DNSKEY RR's owner name and RDATA are hashed using the digest algorithm specified in the DS RR's Digest Type field, the resulting digest value matches the Digest field of the + DS RR. - - -Arends, et al. Expires April 10, 2005 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - - DS RR; and o The matching DNSKEY RR in the child zone has the Zone Flag bit set, the corresponding private key has signed the child zone's apex DNSKEY RRset, and the resulting RRSIG RR authenticates the @@ -1533,7 +1486,7 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 validator can not authenticate RRsets in or below the + RR exists, the validator cannot authenticate RRsets in or below the child zone. If the validator does not support any of the algorithms listed in an @@ -1544,89 +1497,102 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 described above. 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 + 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 + 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 + NSEC RR and child NSEC RR can always be distinguished because 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. + + + + + +Arends, et al. Standards Track [Page 27] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + 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 +5.3. Authenticating an RRset with an RRSIG RR A validator can use an RRSIG RR and its corresponding DNSKEY RR to - - - -Arends, et al. Expires April 10, 2005 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - attempt to authenticate RRsets. The validator first checks the RRSIG RR to verify that it covers the RRset, has a valid time interval, and identifies a valid DNSKEY RR. The validator then constructs the canonical form of the signed data by appending the RRSIG RDATA (excluding the Signature Field) with the canonical form of the covered RRset. Finally, the validator 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. + signature to authenticate the signed data. Sections 5.3.1, 5.3.2, + and 5.3.3 describe each step in detail. -5.3.1 Checking the RRSIG RR Validity +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; + 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; + 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; + or equal to the value in the RRSIG RR's Labels field. + o The validator's notion of the current time MUST be less than or - equal to the time listed in the RRSIG RR's Expiration field; + equal to the time listed in the RRSIG RR's Expiration field. + o The validator's notion of the current time MUST be greater than or - equal to the time listed in the RRSIG RR's Inception field; + 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; + 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. + + + + +Arends, et al. Standards Track [Page 28] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + It is possible for more than one DNSKEY RR to match the conditions above. In this case, the validator cannot predetermine which DNSKEY - RR to use to authenticate the signature, MUST try each matching - DNSKEY RR until either the signature is validated or the validator - has run out of matching public keys to try. + RR to use to authenticate the signature, and it MUST try each + matching DNSKEY RR until either the signature is validated or the + validator has run out of matching public keys to try. Note that this authentication process is only meaningful if the validator 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 + + o the apex DNSKEY RRset containing the DNSKEY RR is considered authentic; or - o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + + 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 trust anchor. -5.3.2 Reconstructing the Signed Data - - - - -Arends, et al. Expires April 10, 2005 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - +5.3.2. Reconstructing the Signed Data Once the RRSIG RR has met the validity requirements described in - Section 5.3.1, the validator needs to reconstruct the original signed + Section 5.3.1, the validator has 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 @@ -1654,6 +1620,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 All names in the RDATA field are in canonical form + + + +Arends, et al. Standards Track [Page 29] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + The set of all RR(i) is sorted into canonical order. To calculate the name: @@ -1673,42 +1647,44 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 if rrsig_labels > fqdn_labels the RRSIG RR did not pass the necessary validation - - - -Arends, et al. Expires April 10, 2005 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - 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]. + The canonical forms for names and RRsets are defined in [RFC4034]. 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. + RRsets 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 as only a child NSEC RR will indicate that 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. 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 + Note 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 + + + + + + + +Arends, et al. Standards Track [Page 30] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +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 @@ -1720,24 +1696,15 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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). - [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types - and provides pointers to the documents that define each algorithm's - use. + of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] + 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 validator can only - determine which DNSKEY RR by trying each matching public key until - the validator either succeeds in validating the signature or runs out - - - -Arends, et al. Expires April 10, 2005 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - - of keys to try. + determine which DNSKEY RR is correct by trying each matching public + key until the validator 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 @@ -1747,33 +1714,46 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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. + policy determines whether the resolver also has to test these RRSIG + RRs and how to resolve conflicts if these RRSIG RRs lead to differing + results. If the resolver accepts the RRset as authentic, the validator 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; - o The value in the RRSIG RR's Original TTL field; and - o The difference of the RRSIG RR's Signature Expiration time and the + + o the RRset's TTL as received in the response; + + o the RRSIG RR's TTL as received in the response; + + o the value in the RRSIG RR's Original TTL field; and + + o the difference of the RRSIG RR's Signature Expiration time and the current time. -5.3.4 Authenticating A Wildcard Expanded RRset Positive Response + + + + +Arends, et al. Standards Track [Page 31] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +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 validator has verified the signature as described in Section - 5.3, it 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. + Once the validator has verified the signature, as described in + Section 5.3, it 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 +5.4. Authenticated Denial of Existence A resolver can use authenticated NSEC RRs to prove that an RRset is not present in a signed zone. Security-aware name servers should @@ -1781,44 +1761,46 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 their responses to security-aware resolvers. Denial of existence is determined by the following rules: + 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 - - - -Arends, et al. Expires April 10, 2005 [Page 32] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - 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. + defined in [RFC4034], 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. In addition, security-aware resolvers MUST authenticate the NSEC RRsets that comprise the non-existence proof as described in Section 5.3. - To prove non-existence of an RRset, the resolver must be able to + To prove the 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 + + + +Arends, et al. Standards Track [Page 32] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + 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 + to verify the 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. @@ -1826,212 +1808,82 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 corresponding RRSIG RR, a validator MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR. -5.5 Resolver Behavior When Signatures Do Not Validate +5.5. Resolver Behavior When Signatures Do Not Validate If for whatever reason none of the RRSIGs can be validated, the response SHOULD be considered BAD. If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client. However, it MUST return the full response if - and only if the original query had the CD bit set. See also Section + and only if the original query had the CD bit set. Also see Section 4.7 on caching responses that do not validate. -5.6 Authentication Example +5.6. Authentication Example Appendix C shows an example of the authentication process. - - - - - -Arends, et al. Expires April 10, 2005 [Page 33] - -Internet-Draft DNSSEC Protocol Modifications October 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: + [RFC4034] contains a review of the IANA considerations introduced by + DNSSEC. The following are 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 + 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 + [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 April 10, 2005 [Page 34] - -Internet-Draft DNSSEC Protocol Modifications October 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-records] for considerations specific to the - DNSSEC resource record types. + Please see [RFC4033] for terminology and general security + considerations related to DNSSEC; see [RFC4034] for considerations + specific to the DNSSEC resource record types. + + + + +Arends, et al. Standards Track [Page 33] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + 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 + protection that 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.9 for further discussion. + channel. See Sections 3.2.2 and 4.9 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 + benefits of DNSSEC to security-oblivious stub resolvers. However, as + 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 + recursive name servers will have to pay close attention to the + behavior of the applications that use their services when choosing a local validation policy; failure to do so could easily result in the recursive name server accidentally denying service to the clients it is intended to support. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 35] - -Internet-Draft DNSSEC Protocol Modifications October 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 April 10, 2005 [Page 36] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. 9. References -9.1 Normative References - - [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-10 (work in progress), May - 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-08 (work in progress), - May 2004. +9.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. @@ -2042,15 +1894,20 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. - [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. + + + +Arends, et al. Standards Track [Page 34] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. @@ -2066,26 +1923,21 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for DNS Security Extensions", RFC + 4034, March 2005. -Arends, et al. Expires April 10, 2005 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - -9.2 Informative References +9.2. 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. + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. @@ -2093,96 +1945,23 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 [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. - - [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) - RDATA Format", RFC 3845, August 2004. - - -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 -Arends, et al. Expires April 10, 2005 [Page 38] + + + + + + + + +Arends, et al. Standards Track [Page 35] -Internet-Draft DNSSEC Protocol Modifications October 2004 - - - 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 - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 39] - -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 Appendix A. Signed Zone Example @@ -2236,9 +2015,9 @@ Appendix A. Signed Zone Example -Arends, et al. Expires April 10, 2005 [Page 40] +Arends, et al. Standards Track [Page 36] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== @@ -2292,9 +2071,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 -Arends, et al. Expires April 10, 2005 [Page 41] +Arends, et al. Standards Track [Page 37] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B @@ -2348,9 +2127,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 -Arends, et al. Expires April 10, 2005 [Page 42] +Arends, et al. Standards Track [Page 38] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 v/iVXSYC0b7mPSU+EOlknFpVECs= ) @@ -2404,9 +2183,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 -Arends, et al. Expires April 10, 2005 [Page 43] +Arends, et al. Standards Track [Page 39] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) @@ -2460,9 +2239,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 -Arends, et al. Expires April 10, 2005 [Page 44] +Arends, et al. Standards Track [Page 40] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 xS9cL2QgW7FChw16mzlkH6/vsfs= ) @@ -2478,13 +2257,13 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 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 + the apex DNSKEY RRset; this is the key that 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 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 @@ -2492,41 +2271,12 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 "a.example" provides a DS RR; note that only the NSEC and DS RRsets are signed. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 45] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - Appendix B. Example Responses The examples in this section show response messages using the signed zone example in Appendix A. -B.1 Answer +B.1. Answer A successful query to an authoritative server. @@ -2542,6 +2292,14 @@ B.1 Answer Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + + + +Arends, et al. Standards Track [Page 41] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) @@ -2569,14 +2327,6 @@ B.1 Answer xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - - - -Arends, et al. Expires April 10, 2005 [Page 46] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ @@ -2599,7 +2349,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) -B.2 Name Error + + +Arends, et al. Standards Track [Page 42] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.2. Name Error An authoritative name error. The NSEC RRs prove that the name does not exist and that no covering wildcard exists. @@ -2625,14 +2382,6 @@ B.2 Name Error ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - - - -Arends, et al. Expires April 10, 2005 [Page 47] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) b.example. 3600 NSEC ns1.example. NS RRSIG NSEC @@ -2656,39 +2405,18 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 ;; (empty) -B.3 No Data Error + + +Arends, et al. Standards Track [Page 43] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.3. No Data Error A "no data" response. The NSEC RR proves that the name exists and that the requested RR type does not. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 48] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - ;; Header: QR AA DO RCODE=0 ;; ;; Question @@ -2724,29 +2452,22 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Additional ;; (empty) - -B.4 Referral to Signed Zone +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. - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 49] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - ;; Header: QR DO RCODE=0 ;; + + + +Arends, et al. Standards Track [Page 44] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + ;; Question mc.a.example. IN MX @@ -2771,36 +2492,11 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6 - -B.5 Referral to Unsigned Zone +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. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 50] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - ;; Header: QR DO RCODE=0 ;; ;; Question @@ -2821,14 +2517,20 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + +Arends, et al. Standards Track [Page 45] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + ;; 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 -B.6 Wildcard Expansion - - A successful query which was answered via wildcard expansion. The + A successful query that 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. @@ -2849,14 +2551,6 @@ B.6 Wildcard Expansion 4kX18MMR34i8lC36SR5xBni8vHI= ) ;; Authority - - - -Arends, et al. Expires April 10, 2005 [Page 51] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS 5 1 3600 20040509183619 ( @@ -2878,6 +2572,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Additional ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + + + +Arends, et al. Standards Track [Page 46] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + 20040409183619 38519 example. pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd @@ -2893,8 +2595,7 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o= ) - -B.7 Wildcard No Data Error +B.7. Wildcard No Data Error A "no data" response for a name covered by a wildcard. The NSEC RRs prove that the matching wildcard name does not have any RRs of the @@ -2905,14 +2606,6 @@ B.7 Wildcard No Data Error ;; Question a.z.w.example. IN AAAA - - - -Arends, et al. Expires April 10, 2005 [Page 52] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - ;; Answer ;; (empty) @@ -2935,6 +2628,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + + + +Arends, et al. Standards Track [Page 47] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr @@ -2951,23 +2652,10 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Additional ;; (empty) +B.8. DS Child Zone No Data Error -B.8 DS Child Zone No Data Error - - A "no data" response for a QTYPE=DS query which was mistakenly sent - to a name server for the child zone. - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 53] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. ;; Header: QR AA DO RCODE=0 ;; @@ -2996,6 +2684,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + + + +Arends, et al. Standards Track [Page 48] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm @@ -3004,113 +2700,92 @@ Internet-Draft DNSSEC Protocol Modifications October 2004 ;; Additional ;; (empty) - - - - - - - - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 54] - -Internet-Draft DNSSEC Protocol Modifications October 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 +C.1. Authenticating an Answer The query in Appendix B.1 returned an MX RRset for "x.w.example.com". - The corresponding RRSIG indicates the MX RRset was signed by an + The corresponding RRSIG indicates that the MX RRset was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. 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, + 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. + 3600. The RRSIG labels field value of 3 indicates that 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 +C.1.1. Authenticating the Example DNSKEY RR This example shows the logical authentication process that starts from the a configured 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 + to authenticate the desired "example" DNSKEY RR. Note that the + logical order is presented for clarity. An implementation may choose + to construct the authentication as referrals are received or 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 configured DNSKEY RR for the + We assume the resolver starts with a configured DNSKEY RR for the root zone (or a configured DS RR for the root zone). The resolver - checks this configured 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 or "example" DS RRset. + checks whether this configured DNSKEY RR is present in the root + DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root + DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY + RRset, and whether the signature lifetime is valid. If all these + + + +Arends, et al. Standards Track [Page 49] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 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 that the + resolver may have to query the root zone to obtain the root DNSKEY + RRset 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 + matching "example" DNSKEY is found, the resolver checks whether this + DNSKEY RR has signed the "example" DNSKEY RRset and the signature + lifetime is valid. If these conditions are met, all keys in the + "example" DNSKEY RRset are considered authenticated. - - -Arends, et al. Expires April 10, 2005 [Page 55] - -Internet-Draft DNSSEC Protocol Modifications October 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" + Finally, the resolver checks that some DNSKEY RR in the "example" DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This - DNSKEY is used to authenticated the RRSIG included in the response. + DNSKEY is used to authenticate the RRSIG included in the response. If multiple "example" DNSKEY RRs match this algorithm and key tag, - then each DNSKEY RR is tried and the answer is authenticated if any - of the matching DNSKEY RRs validates the signature as described - above. + then each DNSKEY RR is tried, and the answer is authenticated if any + of the matching DNSKEY RRs validate the signature as described above. -C.2 Name Error +C.2. Name Error - The query in 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 + The query in Appendix B.2 returned NSEC RRs that prove that 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 +C.3. No Data Error - The query in Appendix B.3 returned an NSEC RR that proves the + The query in Appendix B.3 returned an NSEC RR that proves that 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 +C.4. Referral to Signed Zone The query in Appendix B.4 returned a referral to the signed "a.example." zone. The DS RR is authenticated in a manner identical @@ -3120,58 +2795,59 @@ C.4 Referral to Signed Zone 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. + matching "a.example" DNSKEY is found, the resolver checks whether -C.5 Referral to Unsigned Zone + + +Arends, et al. Standards Track [Page 50] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether + 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 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 identical to that of the MX RRset discussed above. - - -Arends, et al. Expires April 10, 2005 [Page 56] - -Internet-Draft DNSSEC Protocol Modifications October 2004 - - - "example" to "b.example" and the NSEC RR is authenticated in a manner - identical to that of the MX RRset discussed above. - -C.6 Wildcard Expansion +C.6. Wildcard Expansion The query in Appendix B.6 returned an answer that was produced as a result of wildcard expansion. The answer section contains a wildcard - RRset expanded as in a traditional DNS response and the corresponding - RRSIG indicates that the expanded wildcard MX RRset was signed by an - "example" DNSKEY with algorithm 5 and key tag 38519. 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. + RRset expanded as it would be in a traditional DNS response, and the + corresponding RRSIG indicates that the expanded wildcard MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The RRSIG indicates that 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 that the answer + is the result of wildcard expansion, as 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 that 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 + 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 +C.7. Wildcard No Data Error - The query in 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. + The query in Appendix B.7 returned NSEC RRs that prove that 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 +C.8. DS Child Zone No Data Error The query in 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 + indicates the presence of an SOA RR, showing that the answer is from + the child . Queries for the "example" DS RRset should be sent to the parent servers ("root" servers). @@ -3179,21 +2855,84 @@ C.8 DS Child Zone No Data Error - - - - - - - - - -Arends, et al. Expires April 10, 2005 [Page 57] +Arends, et al. Standards Track [Page 51] -Internet-Draft DNSSEC Protocol Modifications October 2004 +RFC 4035 DNSSEC Protocol Modifications March 2005 -Intellectual Property Statement +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC 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 + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.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. Standards Track [Page 52] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -3214,29 +2953,10 @@ Intellectual Property Statement The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment +Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. @@ -3244,6 +2964,8 @@ Acknowledgment -Arends, et al. Expires April 10, 2005 [Page 58] - + + +Arends, et al. Standards Track [Page 53] +