From 84bcefe9eebfc2a775e51c5356150476a07c788d Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 19 May 2004 05:36:35 +0000 Subject: [PATCH] new draft --- ... => draft-ietf-dnsext-dnssec-intro-10.txt} | 2914 ++++---- ... draft-ietf-dnsext-dnssec-protocol-06.txt} | 6498 ++++++++--------- ...> draft-ietf-dnsext-dnssec-records-08.txt} | 4034 +++++----- 3 files changed, 6723 insertions(+), 6723 deletions(-) rename doc/draft/{draft-ietf-dnsext-dnssec-intro-09.txt => draft-ietf-dnsext-dnssec-intro-10.txt} (60%) rename doc/draft/{draft-ietf-dnsext-dnssec-protocol-05.txt => draft-ietf-dnsext-dnssec-protocol-06.txt} (54%) rename doc/draft/{draft-ietf-dnsext-dnssec-records-07.txt => draft-ietf-dnsext-dnssec-records-08.txt} (73%) diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt similarity index 60% rename from doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt rename to doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt index 8097d63455..5ac9cba56e 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt @@ -1,1401 +1,1513 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 16, 2004 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - February 16, 2004 - - - DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-09 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - 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. - - - -Arends, et al. Expires August 16, 2004 [Page 1] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - Last, this document describes the interrelationships between the - group of documents that collectively describe DNSSEC. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 - 3. Services Provided by DNS Security . . . . . . . . . . . . . . 7 - 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 7 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 8 - 4. Services Not Provided by DNS Security . . . . . . . . . . . . 10 - 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 11 - 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 12 - 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 7.1 TTL values vs. RRSIG validity period . . . . . . . . . . . . . 13 - 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13 - 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14 - 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 - Normative References . . . . . . . . . . . . . . . . . . . . . 20 - Informative References . . . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 - Intellectual Property and Copyright Statements . . . . . . . . 24 - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 2] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -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 RFC 2535 [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 9. Section 3 and Section 4 describe the - capabilities and limitations of the security extensions in greater - detail. Section 5, Section 6, Section 7, and Section 8 discuss the - effect that these security extensions will have on resolvers, stub - resolvers, zones and name servers. - - This document and its two companions update and obsolete RFCs 2535 - [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445 - [RFC3445], as well as several works in progress: "Redefinition of the - AD bit" [RFC3655], "Legacy Resolver Compatibility for Delegation - Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation - Signer Resource Record" [RFC3658]. This document set also updates, - but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 - [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 [RFC3597]. - - 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 August 16, 2004 [Page 3] - -Internet-Draft DNSSEC Introduction and Requirements February 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. - - authentication chain: an alternating sequence of DNSKEY RRsets and DS - RRsets forms a chain of signed data, with each link in the chain - vouching for the next. A DNSKEY RR is used to verify the - signature covering a DS RR and allows the DS RR to be - authenticated. The DS RR contains a hash 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 until the chain finally - ends with a DNSKEY RR which signs the desired DNS data. For - example, the root DNSKEY RRset can be used to authenticate the DS - RRset for "example." The "example." DS RRset contains a hash that - matches some "example." DNSKEY and this DNSKEY 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 "subzone.example." - - authentication key: A public key which a security-aware resolver has - verified and can therefore use to authenticate data. A - security-aware resolver can obtain authentication keys in three - ways. First, the resolver is generally preconfigured to know - about at least one public key. This preconfigured data is usually - either the public key itself or a hash of the key as found in the - DS RR. Second, the resolver may use an authenticated public key - to verify a DS RR and its associated DNSKEY RR. Third, the - resolver may be able to determine that a new key has been signed - by another key which the resolver has verified. Note that the - resolver must always be guided by local policy when deciding - whether to authenticate a new key, even if the local policy is - simply to authenticate any new key for which the resolver is able - verify the signature. - - 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). - - 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 with the island's public key - - - -Arends, et al. Expires August 16, 2004 [Page 4] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - in its delegating parent zone (see - [I-D.ietf-dnsext-dnssec-records]). An island of security is served - by a security-aware nameserver 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 zone - key can be authenticated by some trusted means out of band from - the DNS protocol. - - key signing key: An authentication key which is used to sign one or - more other authentication keys for a given zone. Typically, a key - signing key will sign a zone signing key, which in turn 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. Key signing keys are discussed in more - detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone - signing key. - - non-validating security-aware stub resolver: A security-aware stub - resolver which 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 - responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server which will - provide these services on behalf of the security-aware stub - resolver. See also: security-aware stub resolver, validating - security-aware stub resolver. - - non-validating stub resolver: A less tedious term for a - non-validating security-aware stub resolver. - - security-aware name server: An entity acting in the role of a name - server (defined in section 2.4 of [RFC1034]) which understands the - DNS security extensions defined in this document set. In - particular, a security-aware name server is an entity which - 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". - - - -Arends, et al. Expires August 16, 2004 [Page 5] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - security-aware resolver: An entity acting in the role of a resolver - (defined in section 2.4 of [RFC1034]) which understands the DNS - security extensions defined in this document set. In particular, - a security-aware resolver is an entity which 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 - 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 - 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. - - security-oblivious : An which is not - "security-aware". - - signed zone: A zone whose RRsets are signed and which contains - properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS - records. - - unsigned zone: A zone which is not signed. - - validating security-aware stub resolver: A security-aware resolver - which operates sends queries in recursive mode but which performs - signature validation on its own rather than just blindly trusting - a friendly security-aware recursive name server. See also: - security-aware stub resolver, non-validating security-aware stub - resolver. - - validating stub resolver: A less tedious term for a validating - security-aware stub resolver. - - zone signing key: An authentication key which is used to sign a zone. - See key signing key, above. Typically a zone signing key will be - part of the same DNSKEY RRset as the key signing key which signs - it, but 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 distinguish - between zone signing keys and other DNSSEC authentication keys. - See also: key signing key. - - - - -Arends, et al. Expires August 16, 2004 [Page 6] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -3. Services Provided by DNS Security - - The Domain Name System (DNS) security extensions provide origin - authentication and integrity assurance services for DNS data, - including mechanisms for authenticated denial of existence of DNS - data. These mechanisms are described below. - - These mechanisms require changes to the DNS protocol. DNSSEC adds - four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two - new message header bits (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 DO 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 [I-D.ietf-dnsext-dns-threats]. - -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 - 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 - 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). - - A security-aware resolver can learn a zone's public key either by - having the key preconfigured 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 preconfigured authentication key or another key that has - been authenticated previously. Security-aware resolvers authenticate - zone information by forming an authentication chain from a newly - learned public key back to a previously known authentication public - key, which in turn either must have been preconfigured into the - - - -Arends, et al. Expires August 16, 2004 [Page 7] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - resolver or must have been learned and verified previously. - Therefore, the resolver must be configured with at least one public - key or hash of a public key: if the preconfigured key is a zone - signing key, then it will authenticate the associated zone; if the - preconfigured key is a key signing key, it will authenticate a zone - signing key. If the resolver has been preconfigured with the hash of - a key rather than the key itself, the resolver may need 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 in the DNS - reply message along with the public key itself, provided there is - space available in the message. - - The Delegation Signer (DS) RR type simplifies some of the - administrative tasks involved in signing delegations across - organizational boundaries. The DS RRset resides at a delegation - point in a parent zone and indicates the key or keys used by the - delegated child zone to self-sign the DNSKEY RRset at the child - zone's apex. The child zone, in turn, uses one or more of the keys - in this DNSKEY RRset to sign its zone data. The typical - authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where - "*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more - complex authentication chains, such as additional layers of DNSKEY - RRs signing other DNSKEY RRs within a zone. - - A security-aware resolver normally constructs this authentication - chain from the root of the DNS hierarchy down to the leaf zones based - on preconfigured knowledge of the public key for the root. Local - policy, however, may also allow a security-aware resolver to use one - or more preconfigured keys (or key hashes) other than the root key, - or may not provide preconfigured knowledge of the root key, or may - prevent the resolver from using particular keys for arbitrary reasons - even if those 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. - -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 - responses with the same level of authentication and integrity - 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 - - - -Arends, et al. Expires August 16, 2004 [Page 8] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - 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 August 16, 2004 [Page 9] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -4. Services Not Provided by DNS Security - - DNS was originally designed with the assumptions that the DNS will - return the same answer to any given query regardless of who may have - issued the query, and that all data in the DNS is thus visible. - Accordingly, DNSSEC is not designed to provide confidentiality, - access control lists, or other means of differentiating between - inquirers. - - DNSSEC provides no protection against denial of service attacks. - Security-aware resolvers and security-aware name servers are - vulnerable to an additional class of denial of service attacks based - on cryptographic operations. Please see Section 11 for details. - - The DNS security extensions provide data and origin authentication - for DNS data. The mechanisms outlined above are not designed to - protect operations such as zone transfers and dynamic update - [RFC3007]. Message authentication schemes described in [RFC2845] and - [RFC2931] address security operations that pertain to these - transactions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 10] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -5. Resolver Considerations - - A security-aware resolver needs 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 - resolver should be configured with at least one authentication key or - a key's DS RR hash 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 device which acts as a proxy for DNS, and if the recursive name - server or proxy 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 device that includes a DNS proxy which is not - security-aware, the security-aware resolver may find it difficult or - impossible to obtain or validate signed DNS data. - - 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 - 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 - 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 August 16, 2004 [Page 11] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -6. 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 - to offload most of the work of DNS resolution to a recursive name - server. Given the widespread use of stub resolvers, the DNSSEC - 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. - - Even an unaugmented 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) or TSIG - 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. - - A security-aware stub resolver which does trust both its recursive - name servers and its communication channel to them may choose to - examine the setting of the AD bit in the message header of the - response messages it receives. The stub resolver can use this flag - bit as a hint to find out whether the recursive name server was able - to validate signatures for all of the data in the Answer and - Authority sections of the response. - - There is one more step which 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 August 16, 2004 [Page 12] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -7. 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 - 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. - -7.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 - that RRset. DNSSEC does not change the definition or function of the - 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. - - 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 RRset - that it covers. 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. - -7.2 New Temporal Dependency Issues for Zones - - Information in a signed zone has a temporal dependency which 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 - 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 August 16, 2004 [Page 13] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -8. 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 via use of the DO bit in the EDNS header, subject to message - size limitations. Since 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. - - 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 half of 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. - - 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, so 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 August 16, 2004 [Page 14] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -9. 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 "Digital Signature Algorithm Specification" document set refers - to the group of documents that describe how specific digital - signature algorithms should be implemented to fit the DNSSEC resource - record format. Each of these documents deals with a specific digital - signature algorithm. - - 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 - strictly part of the DNSSEC specification as defined in this set of - documents, this group is noted to show 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 August 16, 2004 [Page 15] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -10. 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 August 16, 2004 [Page 16] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -11. Security Considerations - - This document introduces the DNS security extensions and describes - the document set that contains the new security records and DNS - protocol modifications. This document discusses the capabilities and - limitations of these extensions. The extensions provide data origin - authentication and data integrity using digital signatures over - resource record sets. - - 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 - containing the response zones must be signed, and all name servers - and resolvers involved in the resolution process must be - 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 - security-aware resolver cannot validate the affected DNS data. - - This document briefly discusses other methods of adding security to a - DNS query, such as using a channel secured by IPsec or using a DNS - transaction authentication mechanism, but transaction security is not - part of DNSSEC per se. - - A non-validating security-aware stub resolver, by definition, does - 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 - 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 - security-aware stub resolver to perform its own signature validation, - at which point, again by definition, it would no longer be a - non-validating security-aware stub resolver. - - 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 - 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 - needlessly complex signature chains. An attacker may also be able to - - - -Arends, et al. Expires August 16, 2004 [Page 17] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - consume resources in a security-aware name server which 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 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. There are non-DNS - protocol means of detecting and limiting this attack beyond the scope - of this document set. - - 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 - effectively unreachable due to DNSSEC configuration errors or bugs. - - DNSSEC does not provide confidentiality, due to a deliberate design - choice. - - 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 - 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 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 August 16, 2004 [Page 18] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -12. 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 - particularly like to thank the following people for their - contributions to and comments on this document set: Mark Andrews, - Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, - Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael - Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip - Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf - Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted - Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson, - Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik - Rozendaal, Jakob Schlyter, Mike StJohns, Sam Weiler, and Brian - Wellington. - - No doubt the above is an incomplete list. We apologize to anyone we - left out. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 19] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-07 (work in progress), - February 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in - progress), February 2004. - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 20] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -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. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [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. - 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. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [I-D.ietf-dnsext-dns-threats] - Atkins, D. and R. Austein, "Threat Analysis Of The Domain - Name System", draft-ietf-dnsext-dns-threats-05 (work in - progress), November 2003. - - [I-D.ietf-dnsext-dnssec-2535typecode-change] - Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 - - - -Arends, et al. Expires August 16, 2004 [Page 21] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - (work in progress), December 2003. - - [I-D.ietf-dnsext-keyrr-key-signing-flag] - Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", - draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in - progress), December 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - - - - -Arends, et al. Expires August 16, 2004 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 23] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires August 16, 2004 [Page 24] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 25] - - + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: November 15, 2004 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + May 17, 2004 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-10 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + 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. + + + +Arends, et al. Expires November 15, 2004 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + Last, this document describes the interrelationships between the + group of documents that collectively describe DNSSEC. + +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 . . . . . . . . 9 + 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 November 15, 2004 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +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 RFC 2535 [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. + + This document and its two companions update and obsolete RFCs 2535 + [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 + [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress + [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but + does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 + [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts + of 3226 [RFC3226] (dealing with DNSSEC). + + 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 November 15, 2004 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements May 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. + + Authentication Chain: An alternating sequence of DNSKEY RRsets and DS + RRsets forms a chain of signed data, with each link in the chain + vouching for the next. A DNSKEY RR is used to verify the + signature covering a DS RR and allows the DS RR to be + authenticated. The DS RR contains a hash 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 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 "example." The "example." DS + RRset contains a hash that matches 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 "subzone.example." + + Authentication Key: A public key that a security-aware resolver has + verified and can therefore use to authenticate data. A + security-aware resolver can obtain authentication keys in three + ways. First, the resolver is generally configured to know about + at least one public key; this configured data is usually either + the public key itself or a hash of the public key as found in the + DS RR (see "trust anchor"). Second, the resolver may use an + authenticated public key to verify a DS RR and its associated + DNSKEY RR. 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 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. + + 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). + + + + + +Arends, et al. Expires November 15, 2004 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + 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. + + Key Signing Key: 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. + + Non-Validating Security-Aware Stub Resolver: A security-aware stub + resolver which 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 + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server which will + provide these services on behalf of the security-aware stub + resolver. See also: security-aware stub resolver, validating + security-aware stub resolver. + + Non-Validating Stub Resolver: A less tedious term for a + non-validating security-aware stub resolver. + + 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 + 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. + + + +Arends, et al. Expires November 15, 2004 [Page 5] + + + 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 Resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [RFC1034]) which understands the DNS + security extensions defined in this document set. In particular, + a security-aware resolver is an entity which 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 + 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 + 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. + + Security-Oblivious : An that is not + "security-aware". + + Signed Zone: A zone whose RRsets are signed and which contains + properly constructed DNSKEY, RRSIG, 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 + 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 + which the trust anchor points to be signed + + 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 + validation on its own rather than just blindly trusting an + upstream security-aware recursive name server. See also: + security-aware stub resolver, non-validating security-aware stub + resolver. + + + + + +Arends, et al. Expires November 15, 2004 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + Validating Stub Resolver: A less tedious term for a validating + security-aware stub resolver. + + Zone Signing Key: An authentication key that corresponds to a 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 + 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 + 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 + signing key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +3. Services Provided by DNS Security + + The Domain Name System (DNS) security extensions provide origin + authentication and integrity assurance services for DNS data, + including mechanisms for authenticated denial of existence of DNS + data. These mechanisms are described below. + + These mechanisms require changes to the DNS protocol. DNSSEC adds + four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two + new message header bits (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 DO 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 [I-D.ietf-dnsext-dns-threats]. + +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 + 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 + 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). + + 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 + authenticated previously. Security-aware resolvers authenticate zone + information by forming an authentication chain from a newly learned + public key back to a previously known authentication public key, + which in turn either has been configured into the resolver or must + + + +Arends, et al. Expires November 15, 2004 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + have been learned and verified previously. Therefore, the resolver + must be configured with at least one trust anchor. If the configured + key is a zone signing key, then it will authenticate the associated + zone; if the configured key is a key signing key, it will + authenticate a zone signing key. If the resolver has been configured + with the hash of a key rather than the key itself, the resolver may + need 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. + + The Delegation Signer (DS) RR type simplifies some of the + administrative tasks involved in signing delegations across + organizational boundaries. The DS RRset resides at a delegation + point in a parent zone and indicates the public key(s) corresponding + to the private key(s) used to self-sign the DNSKEY RRset at the + delegated child zone's apex. The administrator of the child zone, in + turn, uses the private key(s) corresponding to one or more of the + public keys in this DNSKEY RRset to sign the child zone's data. The + typical authentication chain is therefore + DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more + DS->DNSKEY subchains. DNSSEC permits more complex authentication + chains, such as additional layers of DNSKEY RRs signing other DNSKEY + RRs within a zone. + + A security-aware resolver normally constructs this authentication + chain from the root of the DNS hierarchy down to the leaf zones based + 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 for further + discussion. + +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 + responses with the same level of authentication and integrity + requires the use of another new resource record type, the NSEC + + + +Arends, et al. Expires November 15, 2004 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + 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 + 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 November 15, 2004 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + on cryptographic operations. Please see Section 12 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above are not designed to + protect operations such as zone transfers and dynamic update + [RFC3007]. Message authentication schemes described in [RFC2845] and + [RFC2931] address security operations that pertain to these + transactions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +5. Scope of the DNSSEC Document Set and Last Hop Issues + + The specification in this document set defines the behavior for zone + signers and security-aware name servers and resolvers in such a way + that the validating entities can unambiguously determine the state of + the data. + + A validating resolver can determine these 4 states: + + 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 + branches in the tree are provably insecure. A validating resolver + may have 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. + + Indeterminate: There is no trust anchor which 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 + signal non-validating stub resolvers that data was found to be bogus + (using RCODE=2, "Server Failure" -- see + [I-D.ietf-dnsext-dnssec-protocol]). + + 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]). + + 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. + + 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 + aware resolver and the applications that use it. Note, however, that + + + +Arends, et al. Expires November 15, 2004 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements May 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 November 15, 2004 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +6. Resolver Considerations + + A security-aware resolver needs 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 + 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 device which acts as a proxy for DNS, and if the recursive name + server or proxy 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 device that includes a DNS proxy which is not + security-aware, the security-aware resolver may find it difficult or + impossible to obtain or validate signed DNS data. + + 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 + 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 + 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 November 15, 2004 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +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 + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + 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. + + 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) or + TSIG 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. + + A security-aware stub resolver that does trust both its recursive + name servers and its communication channel to them may choose to + examine the setting of the AD bit in the message header of the + response messages it receives. The stub resolver can use this flag + bit as a hint to find out whether the recursive name server was able + to validate signatures for all of the data in the Answer and + Authority sections of the response. + + 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 November 15, 2004 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +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 + 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. + +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 + that RRset. DNSSEC does not change the definition or function of the + 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. + + 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. + +8.2 New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency which 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 + 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 November 15, 2004 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +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 via use of the DO bit in the EDNS header, subject to message + size limitations. Since 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. + + 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 November 15, 2004 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +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] + + 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. + + The "Digital Signature Algorithm Specification" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + record format. Each document in this set deals with a specific + digital signature algorithm. + + 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 + 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 November 15, 2004 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +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 November 15, 2004 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +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 document discusses the capabilities and + 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 + containing the response zones must be signed, and all name servers + and resolvers involved in the resolution process must be + 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 + security-aware resolver cannot validate the affected DNS data. + + This document briefly discusses other methods of adding security to a + DNS query, such as using a channel secured by IPsec or using a DNS + transaction authentication mechanism, but transaction security is not + part of DNSSEC per se. + + A non-validating security-aware stub resolver, by definition, does + 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 + 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 + security-aware stub resolver to perform its own signature validation, + at which point, again by definition, it would no longer be a + non-validating security-aware stub resolver. + + 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 + 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 + needlessly complex signature chains. An attacker may also be able to + + + +Arends, et al. Expires November 15, 2004 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + consume resources in a security-aware name server which 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 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. There are non-DNS + protocol means of detecting and limiting this attack beyond the scope + of this document set. + + 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 + effectively unreachable due to DNSSEC configuration errors or bugs. + + DNSSEC does not provide confidentiality, due to a deliberate design + choice. + + 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 + 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 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 November 15, 2004 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +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 + particularly like to thank the following people for their + contributions to and comments on this document set: Mark Andrews, + Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, + Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael + Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip + Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf + Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted + Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson, + Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik + Rozendaal, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, and + Brian Wellington. + + No doubt the above list is incomplete. We apologize to anyone we + left out. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements May 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. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + +14.2 Informative References + + [I-D.ietf-dnsext-dns-threats] + Atkins, D. and R. Austein, "Threat Analysis Of The Domain + Name System", draft-ietf-dnsext-dns-threats-07 (work in + progress), April 2004. + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "KEY RR Secure Entry Point Flag", + draft-ietf-dnsext-nsec-rdata-05 (work in progress), March + 2004. + + + +Arends, et al. Expires November 15, 2004 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + [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. + + [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. + 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. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [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. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 24] + +Internet-Draft DNSSEC Introduction and Requirements May 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 + + + 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 November 15, 2004 [Page 25] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires November 15, 2004 [Page 26] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 27] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt similarity index 54% rename from doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt rename to doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt index 1a9f8aaf7a..a6f628e3c7 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt @@ -1,3249 +1,3249 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 16, 2004 M. Larson - VeriSign - R. Austein - ISC - D. Massey - USC/ISI - S. Rose - NIST - February 16, 2004 - - - Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-05 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents which describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of new resource records and protocol modifications which - add data origin authentication and data integrity to the DNS. This - document describes the DNSSEC protocol modifications. This document - - - -Arends, et al. Expires August 16, 2004 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - defines the concept of a signed zone, along with the requirements for - serving and resolving using DNSSEC. These techniques allow a - security-aware resolver to authenticate both DNS resource records and - authoritative DNS error indications. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7 - 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 - 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10 - 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11 - 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11 - 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12 - 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14 - 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16 - 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17 - 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17 - 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20 - 4.3 Determining Security Status of Data . . . . . . . . . . . . 21 - 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 22 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 22 - 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22 - 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 23 - 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24 - 4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24 - 4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24 - - - -Arends, et al. Expires August 16, 2004 [Page 2] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - 4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 26 - 5.1 Special Considerations for Islands of Security . . . . . . . 27 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 27 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 28 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 30 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 31 - 5.3.4 Authenticating A Wildcard Expanded RRset Positive - Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 32 - 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 33 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 35 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 - Normative References . . . . . . . . . . . . . . . . . . . . 37 - Informative References . . . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . 46 - B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 47 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 48 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 49 - B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 50 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 52 - C. Authentication Examples . . . . . . . . . . . . . . . . . . 54 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 54 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 55 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 55 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 55 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . 57 - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications which add data origin - authentication and data integrity to the DNS. This document defines - the DNSSEC protocol modifications. Section 2 of this document defines - the concept of a signed zone and lists the requirements for zone - signing. Section 3 describes the modifications to authoritative name - server behavior necessary to handle signed zones. Section 4 describes - the behavior of entities which include security-aware resolver - functions. Finally, Section 5 defines how to use DNSSEC RRs to - authenticate a response. - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034] and RFC1035 [RFC1035]. - - This document is part of a family of documents which define DNSSEC. - An introduction to DNSSEC and definition of common terms can be found - in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC - resource records can be found in [I-D.ietf-dnsext-dnssec-records]. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Open Technical Issues - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - - - - -Arends, et al. Expires August 16, 2004 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -2. Zone Signing - - DNSSEC introduces the concept of signed zones. A signed zone - includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to - the rules specified in Section 2.1, Section 2.2, Section 2.3 and - Section 2.4, respectively. A zone that does not include these - records according to the rules in this section is an unsigned zone. - - DNSSEC requires a change to the definition of the CNAME resource - record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG - and NSEC RRs to appear at the same owner name as a CNAME RR. - -2.1 Including DNSKEY RRs in a Zone - - To sign a zone, the zone's administrator generates one or more - public/private key pairs and uses the private key(s) to sign - authoritative RRsets in the zone. For each private key used to - create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with - the public component stored in the zone. A zone key DNSKEY RR MUST - have the Zone Key bit of the flags RDATA field set to one -- see - Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys - associated with other DNS operations MAY be stored in DNSKEY RRs that - are not marked as zone keys but MUST NOT be used to verify RRSIGs. - - If the zone is delegated and does not wish to act as an island of - security, the zone MUST have at least one DNSKEY RR at the apex to - act as a secure entry point into the zone. This DNSKEY would then be - used to generate a DS RR at the delegating parent (see - [I-D.ietf-dnsext-dnssec-records]). - - DNSKEY RRs MUST NOT appear at delegation points. - -2.2 Including RRSIG RRs in a Zone - - For each authoritative RRset in a signed zone, there MUST be at least - one RRSIG record that meets all of the following requirements: - - o The RRSIG owner name is equal to the RRset owner name; - - o The RRSIG class is equal to the RRset class; - - o The RRSIG Type Covered field is equal to the RRset type; - - o The RRSIG Original TTL field is equal to the TTL of the RRset; - - o The RRSIG RR's TTL is equal to the TTL of the RRset; - - o The RRSIG Labels field is equal to the number of labels in the - - - -Arends, et al. Expires August 16, 2004 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - RRset owner name, not counting the null root label and not - counting the leftmost label if it is a wildcard; - - o The RRSIG Signer's Name field is equal to the name of the zone - containing the RRset; and - - o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a - zone key DNSKEY record at the zone apex. - - The process for constructing the RRSIG RR for a given RRset is - described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have - multiple RRSIG RRs associated with it. - - An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR - would add no value and would create an infinite loop in the signing - process. - - The NS RRset that appears at the zone apex name MUST be signed, but - the NS RRsets that appear at delegation points (that is, the NS - RRsets in the parent zone that delegate the name to the child zone's - name servers) MUST NOT be signed. Glue address RRsets associated with - delegations MUST NOT be signed. - - There MUST be an RRSIG for each RRset using at least one DNSKEY of - each algorithm in the parent zone's DS RRset and each additional - algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset - itself MUST be signed by each algorithm appearing in the DS RRset. - -2.3 Including NSEC RRs in a Zone - - Each owner name in the zone which has authoritative data or a - delegation point NS RRset MUST have an NSEC resource record. The - process for constructing the NSEC RR for a given name is described in - [I-D.ietf-dnsext-dnssec-records]. - - The TTL value for any NSEC RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - An NSEC record (and its associated RRSIG RRset) MUST NOT be the only - RRset at any particular owner name. That is, the signing process - MUST NOT create NSEC or RRSIG RRs for owner names nodes which were - not the owner name of any RRset before the zone was signed. - - The type bitmap of every NSEC resource record in a signed zone MUST - indicate the presence of both the NSEC record itself and its - corresponding RRSIG record. - - The difference between the set of owner names that require RRSIG - - - -Arends, et al. Expires August 16, 2004 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - records and the set of owner names that require NSEC records is - subtle and worth highlighting. RRSIG records are present at the - owner names of all authoritative RRsets. NSEC records are present at - the owner names of all names for which the signed zone is - authoritative and also at the owner names of delegations from the - signed zone to its children. Neither NSEC nor RRSIG records are - present (in the parent zone) at the owner names of glue address - RRsets. Note, however, that this distinction is for the most part is - only visible during the zone signing process, because NSEC RRsets are - authoritative data, and are therefore signed, thus any owner name - which has an NSEC RRset will have RRSIG RRs as well in the signed - zone. - -2.4 Including DS RRs in a Zone - - The DS resource record establishes authentication chains between DNS - zones. A DS RRset SHOULD be present at a delegation point when the - child zone is signed. The DS RRset MAY contain multiple records, - each referencing a public key in the child zone used to verify the - RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS - RRsets MUST NOT appear at a zone's apex. - - A DS RR SHOULD point to a DNSKEY RR which is present in the child's - apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. - - The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset - (i.e., the NS RRset from the same zone containing the DS RRset). - - Construction of a DS RR requires knowledge of the corresponding - DNSKEY RR in the child zone, which implies communication between the - child and parent zones. This communication is an operational matter - not covered by this document. - -2.5 Changes to the CNAME Resource Record. - - If a CNAME RRset is present at a name in a signed zone, appropriate - RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that - name for secure dynamic update purposes is also allowed. Other types - MUST NOT be present at that name. - - This is a modification to the original CNAME definition given in - [RFC1034]. The original definition of the CNAME RR did not allow any - other types to coexist with a CNAME record, but a signed zone - requires NSEC and RRSIG RRs for every authoritative name. To resolve - this conflict, this specification modifies the definition of the - CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. - - - - -Arends, et al. Expires August 16, 2004 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -2.6 Example of a Secure Zone - - Appendix A shows a complete example of a small signed zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3. Serving - - This section describes the behavior of entities that include - security-aware name server functions. In many cases such functions - will be part of a security-aware recursive name server, but a - security-aware authoritative name server has some of the same - requirements as a security-aware recursive name server does. - Functions specific to security-aware recursive name servers are - described in Section 3.2; functions specific to authoritative servers - are described in Section 3.1. - - The terms "SNAME", "SCLASS", and "STYPE" in the following discussion - are as used in [RFC1034]. - - A security-aware name server MUST support the EDNS0 [RFC2671] message - size extension, MUST support a message size of at least 1220 octets, - and SHOULD support a message size of 4000 octets [RFC3226]. - - A security-aware name server that receives a DNS query that does not - include the EDNS OPT pseudo-RR or that has the DO bit set to zero - MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other - RRset, and MUST NOT perform any of the additional processing - described below. Since the DS RR type has the peculiar property of - only existing in the parent zone at delegation points, DS RRs always - require some special processing, as described in Section 3.1.4.1. - - DNSSEC allocates two new bits in the DNS message header: the CD - (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit - is controlled by resolvers; a security-aware name server MUST copy - the CD bit from a query into the corresponding response. The AD bit - is controlled by name servers; a security-aware name server MUST - ignore the setting of the AD bit in queries. See Section 3.1.6, - Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details - on the behavior of these bits. - -3.1 Authoritative Name Servers - - Upon receiving a relevant query that has the EDNS [RFC2671] OPT - pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative - name server for a signed zone MUST include additional RRSIG, NSEC, - and DS RRs according to the following rules: - - o RRSIG RRs that can be used to authenticate a response MUST be - included in the response according to the rules in Section 3.1.1; - - o NSEC RRs that can be used to provide authenticated denial of - existence MUST be included in the response automatically according - to the rules in Section 3.1.3; - - - -Arends, et al. Expires August 16, 2004 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST - be included in referrals automatically according to the rules in - Section 3.1.4. - - DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 - discusses zone transfer requirements. - -3.1.1 Including RRSIG RRs in a Response - - When responding to a query that has the DO bit set to one, a - security-aware authoritative name server SHOULD attempt to send RRSIG - RRs that a security-aware resolver can use to authenticate the RRsets - in the response. Inclusion of RRSIG RRs in a response is subject to - the following rules: - - o When placing a signed RRset in the Answer section, the name server - MUST also place its RRSIG RRs in the Answer section. The RRSIG - RRs have a higher priority for inclusion than any other RRsets - that may need to be included. If space does not permit inclusion - of these RRSIG RRs, the name server MUST set the TC bit. - - o When placing a signed RRset in the Authority section, the name - server MUST also place its RRSIG RRs in the Authority section. - The RRSIG RRs have a higher priority for inclusion than any other - RRsets that may need to be included. If space does not permit - inclusion of these RRSIG RRs, the name server MUST set the TC bit. - - o When placing a signed RRset in the Additional section, the name - server MUST also place its RRSIG RRs in the Additional section. - If space does not permit inclusion of both the RRset and its - associated RRSIG RRs, the name server MUST NOT set the TC bit - solely because these RRSIG RRs didn't fit. - - -3.1.2 Including DNSKEY RRs In a Response - - When responding to a query that has the DO bit set to one and that - requests the SOA or NS RRs at the apex of a signed zone, a - security-aware authoritative name server for that zone MAY return the - zone apex DNSKEY RRset in the Additional section. In this situation, - the DNSKEY RRset and associated RRSIG RRs have lower priority than - any other information that would be placed in the additional section. - The name server SHOULD NOT include the DNSKEY RRset unless there is - enough space in the response message for both the DNSKEY RRset and - its associated RRSIG RR(s). If there is not enough space to include - these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST - NOT set the TC bit solely because these RRs didn't fit (see Section - 3.1.1). - - - -Arends, et al. Expires August 16, 2004 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3.1.3 Including NSEC RRs In a Response - - When responding to a query that has the DO bit set to one, a - security-aware authoritative name server for a signed zone MUST - include NSEC RRs in each of the following cases: - - No Data: The zone contains RRsets that exactly match , - but does not contain any RRsets that exactly match . - - Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. - - Wildcard Answer: The zone does not contain any RRsets that exactly - match but does contain an RRset that matches - via wildcard name expansion. - - Wildcard No Data: The zone does not contain any RRsets that exactly - match , does contain one or more RRsets that match - via wildcard name expansion, but does not contain - any RRsets that match via wildcard name - expansion. - - In each of these cases, the name server includes NSEC RRs in the - response to prove that an exact match for was - not present in the zone and that the response that the name server is - returning is correct given the data that are in the zone. - -3.1.3.1 Including NSEC RRs: No Data Response - - If the zone contains RRsets matching but contains no - RRset matching , then the name server MUST - include the NSEC RR for along with its associated - RRSIG RR(s) in the Authority section of the response (see Section - 3.1.1). If space does not permit inclusion of the NSEC RR or its - associated RRSIG RR(s), the name server MUST set the TC bit (see - Section 3.1.1). - - Since the search name exists, wildcard name expansion does not apply - to this query, and a single signed NSEC RR suffices to prove the - requested RR type does not exist. - -3.1.3.2 Including NSEC RRs: Name Error Response - - If the zone does not contain any RRsets matching - either exactly or via wildcard name expansion, then the name server - MUST include the following NSEC RRs in the Authority section, along - with their associated RRSIG RRs: - - - -Arends, et al. Expires August 16, 2004 [Page 12] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o An NSEC RR proving that there is no exact match for ; and - - o An NSEC RR proving that the zone contains no RRsets that would - match via wildcard name expansion. - - In some cases a single NSEC RR may prove both of these points, in - that case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - Note that this form of response includes cases in which SNAME - corresponds to an empty non-terminal name within the zone (a name - which is not the owner name for any RRset but which is the parent - name of one or more RRsets). - -3.1.3.3 Including NSEC RRs: Wildcard Answer Response - - If the zone does not contain any RRsets which exactly match but does contain an RRset which matches via wildcard name expansion, the name server MUST include the - wildcard-expanded answer and the corresponding wildcard-expanded - RRSIG RRs in the Answer section, and MUST include in the Authority - section an NSEC RR and associated RRSIG RR(s) proving that the zone - does not contain a closer match for . If space does - not permit inclusion of the answer, NSEC and RRSIG RRs, the name - server MUST set the TC bit (see Section 3.1.1). - -3.1.3.4 Including NSEC RRs: Wildcard No Data Response - - This case is a combination of the previous cases. The zone does not - contain an exact match for , and while the zone does - contain RRsets which match via wildcard expansion, - none of those RRsets match STYPE. The name server MUST include the - following NSEC RRs in the Authority section, along with their - associated RRSIG RRs: - - o An NSEC RR proving that there are no RRsets matching STYPE at the - wildcard owner name which matched via wildcard - expansion; and - - o An NSEC RR proving that there are no RRsets in the zone which - - - -Arends, et al. Expires August 16, 2004 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - would have been a closer match for . - - In some cases a single NSEC RR may prove both of these points, in - which case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - -3.1.3.5 Finding The Right NSEC RRs - - As explained above, there are several situations in which a - security-aware authoritative name server needs to locate an NSEC RR - which proves that a particular SNAME does not exist. Locating such - an NSEC RR within an authoritative zone is relatively simple, at - least in concept. The following discussion assumes that the name - server is authoritative for the zone which would have held the - nonexistent SNAME. The algorithm below is written for clarity, not - efficiency. - - To find the NSEC which proves that name N does not exist in the zone - Z which would have held it, construct sequence S consisting of every - name in Z, sorted into canonical order - [I-D.ietf-dnsext-dnssec-records]. Find the name M which would have - immediately preceded N in S if N had existed. M is the owner name of - the NSEC RR which proves that N does not exist. - - The algorithm for finding the NSEC RR which proves that a given name - is not covered by any applicable wildcard is similar, but requires an - extra step. More precisely, the algorithm for finding the NSEC - proving that the applicable wildcard name does not exist is precisely - the same as the algorithm for finding the NSEC RR which proves that - any other name does not exist: the part that's missing is how to - determine the name of the nonexistent applicable wildcard. In - practice, this is easy, because the authoritative name server has - already checked for the presence of precisely this wildcard name as - part of step (1)(c) of the normal lookup algorithm described in - Section 4.3.2 of [RFC1034]. - -3.1.4 Including DS RRs In a Response - - When responding to a query which has the DO bit set to one, a - security-aware authoritative name server returning a referral - includes DNSSEC data along with the NS RRset. - - - -Arends, et al. Expires August 16, 2004 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - If a DS RRset is present at the delegation point, the name server - MUST return both the DS RRset and its associated RRSIG RR(s) in the - Authority section along with the NS RRset. The name server MUST - place the NS RRset before the DS RRset and its associated RRSIG - RR(s). - - If no DS RRset is present at the delegation point, the name server - MUST return both the NSEC RR which proves that the DS RRset is not - present and the NSEC RR's associated RRSIG RR(s) along with the NS - RRset. The name server MUST place the NS RRset before the NSEC RRset - and its associated RRSIG RR(s). - - Including these DS, NSEC, and RRSIG RRs increases the size of - referral messages, and may cause some or all glue RRs to be omitted. - If space does not permit inclusion of the DS or NSEC RRset and - associated RRSIG RRs, the name server MUST set the TC bit (see - Section 3.1.1). - -3.1.4.1 Responding to Queries for DS RRs - - The DS resource record type is unusual in that it appears only on the - parent zone's side of a zone cut. For example, the DS RRset for the - delegation of "foo.example" is stored in the "example" zone rather - than in the "foo.example" zone. This requires special processing - rules for both name servers and resolvers, since the name server for - the child zone is authoritative for the name at the zone cut by the - normal DNS rules but the child zone does not contain the DS RRset. - - A security-aware resolver sends queries to the parent zone when - looking for a needed DS RR at a delegation point (see Section 4.2). - However, special rules are necessary to avoid confusing - security-oblivious resolvers which might become involved in - processing such a query (for example, in a network configuration that - forces a security-aware resolver to channel its queries through a - security-oblivious recursive name server). The rest of this section - describes how a security-aware name server processes DS queries in - order to avoid this problem. - - The need for special processing by a security-aware name server only - arises when all the following conditions are met: - - o the name server has received a query for the DS RRset at a zone - cut; and - - o the name server is authoritative for the child zone; and - - o the name server is not authoritative for the parent zone; and - - - - -Arends, et al. Expires August 16, 2004 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o the name server does not offer recursion. - - In all other cases, the name server either has some way of obtaining - the DS RRset or could not have been expected to have the DS RRset - even by the pre-DNSSEC processing rules, so the name server can - return either the DS RRset or an error response according to the - normal processing rules. - - If all of the above conditions are met, however, the name server is - authoritative for SNAME but cannot supply the requested RRset. In - this case, the name server MUST return an authoritative "no data" - response showing that the DS RRset does not exist in the child zone's - apex. See Appendix B.8 for an example of such a response. - -3.1.5 Responding to Queries for Type AXFR or IXFR - - DNSSEC does not change the DNS zone transfer process. A signed zone - will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these - records have no special meaning with respect to a zone transfer - operation, and these RRs are treated as any other resource record - type. - - An authoritative name server is not required to verify that a zone is - properly signed before sending or accepting a zone transfer. - However, an authoritative name server MAY choose to reject the entire - zone transfer if the zone fails meets any of the signing requirements - described in Section 2. The primary objective of a zone transfer is - to ensure that all authoritative name servers have identical copies - of the zone. An authoritative name server which chooses to perform - its own zone validation MUST NOT selectively reject some RRs and - accept others. - - DS RRsets appear only on the parental side of a zone cut and are - authoritative data in the parent zone. As with any other - authoritative RRset, the DS RRset MUST be included in zone transfers - of the zone in which the RRset is authoritative data: in the case of - the DS RRset, this is the parent zone. - - NSEC RRs appear in both the parent and child zones at a zone cut, and - are authoritative data in both the parent and child zones. The - parental and child NSEC RRs at a zone cut are never identical to each - other, since the NSEC RR in the child zone's apex will always - indicate the presence of the child zone's SOA RR while the parental - NSEC RR at the zone cut will never indicate the presence of an SOA - RR. As with any other authoritative RRs, NSEC RRs MUST be included - in zone transfers of the zone in which they are authoritative data: - the parental NSEC RR at a zone cut MUST be included zone transfers of - the parent zone, while the NSEC at the zone apex of the child zone - - - -Arends, et al. Expires August 16, 2004 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - MUST be included in zone transfers of the child zone. - - RRSIG RRs appear in both the parent and child zones at a zone cut, - and are authoritative in whichever zone contains the authoritative - RRset for which the RRSIG RR provides the signature. That is, the - RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be - authoritative in the parent zone, while the RRSIG for any RRset in - the child zone's apex will be authoritative in the child zone. As - with any other authoritative RRs, RRSIG RRs MUST be included in zone - transfers of the zone in which they are authoritative data. - -3.1.6 The AD and CD Bits in an Authoritative Response - - The CD and AD bits are designed to be used in communication between - security-aware resolvers and security-aware recursive name servers. - This bits are for the most part not relevant to query processing by - security-aware authoritative name servers. - - Since a security-aware name server does not perform signature - validation for authoritative data during query processing even when - the CD bit is set to zero, a security-aware name server SHOULD ignore - the setting of the CD bit when composing an authoritative response. - - A security-aware name server MUST NOT set the AD bit in a response - unless the name server considers all RRsets in the Answer and - Authority sections of the response to be authentic. A security-aware - name server's local policy MAY consider data from an authoritative - zone to be authentic without further validation, but the name server - MUST NOT do so unless the name server obtained the authoritative zone - via secure means (such as a secure zone transfer mechanism), and MUST - NOT do so unless this behavior has been configured explicitly. - - A security-aware name server which supports recursion MUST follow the - rules for the CD and AD bits given in Section 3.2 when generating a - response that involves data obtained via recursion. - -3.2 Recursive Name Servers - - As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware - recursive name server is an entity which acts in both the - security-aware name server and security-aware resolver roles. This - section uses the terms "name server side" and "resolver side" to - refer to the code within a security-aware recursive name server which - implements the security-aware name server role and the code which - implements the security-aware resolver role, respectively. - - The resolver side follows the usual rules for caching and negative - caching which would apply to any security-aware resolver. - - - -Arends, et al. Expires August 16, 2004 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3.2.1 The DO bit - - The resolver side of a security-aware recursive name server MUST set - the DO bit when sending requests, regardless of the state of the DO - bit in the initiating request received by the name server side. If - the DO bit in an initiating query is not set, the name server side - MUST strip any authenticating DNSSEC RRs from the response, but MUST - NOT strip any DNSSEC RRs that the initiating query explicitly - requested. - -3.2.2 The CD bit - - The CD bit exists in order to allow a security-aware resolver to - disable signature validation in a security-aware name server's - processing of a particular query. - - The name server side MUST copy the setting of the CD bit from a query - to the corresponding response. - - The name server side of a security-aware recursive name server MUST - pass the sense of the CD bit to the resolver side along with the rest - of an initiating query, so that the resolver side will know whether - or not it is required to verify the response data it returns to the - name server side. If the CD bit is set to one, it indicates that the - originating resolver is willing to perform whatever authentication - its local policy requires, thus the resolver side of the recursive - name server need not perform authentication on the RRsets in the - response. When the CD bit is set to one the recursive name server - SHOULD, if possible, return the requested data to the originating - resolver even if the recursive name server's local authentication - policy would reject the records in question. That is, by setting the - CD bit, the originating resolver has indicated that it takes - responsibility for performing its own authentication, and the - recursive name server should not interfere. - - If the resolver side implements a BAD cache (see Section 4.7) and the - name server side receives a query which matches an entry in the - resolver side's BAD cache, the name server side's response depends on - the sense of the CD bit in the original query. If the CD bit is set, - the name server side SHOULD return the data from the BAD cache; if - the CD bit is not set, the name server side MUST return RCODE 2 - (server failure). - -3.2.3 The AD bit - - The name server side of a security-aware recursive name server MUST - NOT set the AD bit in a response unless the name server considers all - RRsets in the Answer and Authority sections of the response to be - - - -Arends, et al. Expires August 16, 2004 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - authentic, and SHOULD set the AD bit if and only if the resolver side - considers all RRsets in the Answer section and any relevant negative - response RRs in the Authority section to be authentic. The resolver - side MUST follow the procedure described in Section 5 to determine - whether the RRs in question are authentic. - -3.3 Example DNSSEC Responses - - See Appendix B for example response packets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -4. Resolving - - This section describes the behavior of entities which include - security-aware resolver functions. In many cases such functions will - be part of a security-aware recursive name server, but a stand-alone - security-aware resolver has many of the same requirements. Functions - specific to security-aware recursive name servers are described in - Section 3.2. - -4.1 EDNS Support - - A security-aware resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set to one when sending queries. - - A security-aware resolver MUST support a message size of at least - 1220 octets, SHOULD support a message size of 4000 octets, and MUST - advertise the supported message size using the "sender's UDP payload - size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST - handle fragmented UDP packets correctly regardless of whether any - such fragmented packets were received via IPv4 or IPv6. Please see - [RFC3226] for discussion of these requirements. - -4.2 Signature Verification Support - - A security-aware resolver MUST support the signature verification - mechanisms described in Section 5, and MUST apply them to every - received response except when: - - o The security-aware resolver is part of a security-aware recursive - name server, and the response is the result of recursion on behalf - of a query received with the CD bit set; - - o The response is the result of a query generated directly via some - form of application interface which instructed the security-aware - resolver not to perform validation for this query; or - - o Validation for this query has been disabled by local policy. - - A security-aware resolver's support for signature verification MUST - include support for verification of wildcard owner names. - - Editors' note: The rest of this section is expected to change once - the WG reaches closure on Q-23. - - A security-aware resolver MUST attempt to retrieve missing DS, - DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these - RRs in order to perform signature verification. - - - - -Arends, et al. Expires August 16, 2004 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - A security-aware resolver MUST attempt to retrieve a missing NSEC RR - which the resolver needs to authenticate a NODATA response. In - general it is not possible for a resolver to retrieve missing NSEC - RRs, since the resolver will have no way of knowing the owner name of - the missing NSEC RR, but in the specific case of a NODATA response, - the resolver may know the name of the missing NSEC RR, and in such - cases must therefore attempt to retrieve it. - - When attempting to retrieve missing NSEC RRs which reside on the - parental side at a zone cut, a security-aware iterative-mode resolver - MUST query the name servers for the parent zone, not the child zone. - - When attempting to retrieve a missing DS, a security-aware - iterative-mode resolver MUST query the name servers for the parent - zone, not the child zone. As explained in Section 3.1.4.1, - security-aware name servers need to apply special processing rules to - handle the DS RR, and in some situations the resolver may also need - to apply special rules to locate the name servers for the parent zone - if the resolver does not already have the parent's NS RRset. To - locate the parent NS RRset, the resolver can start with the - delegation name, strip off the leftmost label, and query for an NS - RRset by that name; if no NS RRset is present at that name, the - resolver then strips of the leftmost remaining label and retries the - query for that name, repeating this process of walking up the tree - until it either finds the NS RRset or runs out of labels. - - Editors' note: This algorithm could easily be read as an - invitation to careless implementors to hammer the root zone - servers. Better wording would be welcome. - - -4.3 Determining Security Status of Data - - Editors' note: This section is waiting for resolution of Q-28. - - A security-aware resolver MUST be able to determine whether or not it - should expect a particular RRset to be signed. More precisely, a - security-aware resolver must be able to distinguish between three - cases: - - 1. An RRset for which the resolver is able to build a chain of - signed DNSKEY and DS RRs from a trusted security anchor to the - RRset. In this case, the RRset should be signed, and is subject - to signature validation as described above. - - 2. An RRset for which the resolver knows that it has no chain of - signed DNSKEY and DS RRs from any trusted starting point to the - RRset. This can occur when the target RRset lies in an unsigned - - - -Arends, et al. Expires August 16, 2004 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - zone or in a descendent of an unsigned zone. In this case, the - RRset may or may not be signed, but the resolver will not be able - to verify the signature. - - 3. An RRset for which the resolver is not able to determine whether - or not the RRset should be signed, because the resolver is not - able to obtain the necessary DNSSEC RRs. This can occur when the - security-aware resolver is not able to contact security-aware - name servers for the relevant zones. - - -4.4 Preconfigured Public Keys - - A security-aware resolver MUST be capable of being preconfigured with - at least one trusted public key or DS RR, and SHOULD be capable of - being preconfigured with multiple trusted public keys or DS RRs. - Since a security-aware resolver will not be able to validate - signatures without such a preconfigured trusted key, the resolver - SHOULD have some reasonably robust mechanism for obtaining such keys - when it boots; examples of such a mechanism would be some form of - non-volatile storage (such as a disk drive) or some form of trusted - local network configuration mechanism. - -4.5 Response Caching - - Editors' note: RIPE "last call" workshop felt that the WG needs to - reexamine and discuss this section. - - A security-aware resolver SHOULD cache each response as a single - atomic entry containing the entire answer, including the named RRset - and any associated DNSSEC RRs. The resolver SHOULD discard the - entire atomic entry when any of the RRs contained in it expire. In - most cases the appropriate cache index for the atomic entry will be - the triple , but in cases such as the response - form described in Section 3.1.3.2 the appropriate cache index will be - the double . - -4.6 Handling of the CD and AD bits - - A security-aware resolver MAY set the CD bit in a query to one in - order to indicate that the resolver takes responsibility for - performing whatever authentication its local policy requires on the - RRsets in the response. See Section 3.2 for the effect this bit has - on the behavior of security-aware recursive name servers. - - A security-aware resolver MUST zero the AD bit when composing query - messages to protect against buggy name servers which blindly copy - header bits which they do not understand from the query message to - - - -Arends, et al. Expires August 16, 2004 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - the response message. - - A resolver MUST disregard the meaning of the CD and AD bits in a - response unless the response was obtained using a secure channel or - the resolver was specifically configured to regard the message header - bits without using a secure channel. - -4.7 Rate Limiting - - A security-aware resolver SHOULD NOT cache data with invalid - signatures under normal circumstances. However, a security-aware - resolver SHOULD take steps to rate limit the number of identical - queries that it generates if signature validation of the responses - fails repeatedly. - - Conceptually, this is similar in some respects to negative caching - [RFC2308], but since the resolver has no way of obtaining an - appropriate caching TTL from received data in this case, the TTL will - have to be set by the implementation. This document refers to the - data retained as part of such a rate limiting mechanism as the "BAD - cache". - - A security-aware resolver MAY chose to retain RRsets for which - signature validation has failed in its BAD cache, but MUST NOT return - such RRsets from its BAD cache unless both of the following - conditions are met: - - o The resolver has recently generated enough queries identical to - this one that the resolver is suppressing queries for this ; and - - o The resolver is not required to validate the signatures of the - RRsets in question under the rules given in Section 4 of this - document. - - The intent of the above rule is to provide the raw data to clients - which are capable of performing their own signature verification - checks while protecting clients which depend on this resolver to - perform such checks. Several of the possible reasons why signature - validation might fail involve conditions which may not apply equally - to this resolver and the client which invoked it: for example, this - resolver's clock may be set incorrectly, or the client may have - knowledge of a relevant island of security which this resolver does - not share. In such cases, "protecting" a client which is capable of - performing its own signature validation from ever seeing the "bad" - data does not help the client. - - - - - -Arends, et al. Expires August 16, 2004 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -4.8 Stub resolvers - - A security-aware stub resolver MUST support the DNSSEC RR types, at - least to the extent of not mishandling responses just because they - contain DNSSEC RRs. - -4.8.1 Handling of the DO Bit - - A non-validating security-aware stub resolver MAY include the DNSSEC - RRs returned by a security-aware recursive name server as part of the - data that the stub resolver hands back to the application which - invoked it but is not required to do so. A non-validating stub - resolver that wishes to do this will need to set the DO bit in - receive DNSSEC RRs from the recursive name server. - - A validating security-aware stub resolver MUST set the DO bit, since - otherwise it will not receive the DNSSEC RRs it needs to perform - signature validation. - -4.8.2 Handling of the CD Bit - - A non-validating security-aware stub resolver SHOULD NOT set the CD - bit when sending queries unless requested by the application layer, - since by definition, a non-validating stub resolver depends on the - security-aware recursive name server to perform validation on its - behalf. - - A validating security-aware stub resolver SHOULD set the CD bit, - since otherwise the security-aware recursive name server will answer - the query using the name server's local policy, which may prevent the - stub resolver from receiving data which would be acceptable to the - stub resolver's local policy. - -4.8.3 Handling of the AD Bit - - A non-validating security-aware stub resolver MAY chose to examine - the setting of the AD bit in response messages that it receives in - order to determine whether the security-aware recursive name server - which sent the response claims to have cryptographically verified the - data in the Answer and Authority sections of the response message. - Note, however, that the responses received by a security-aware stub - resolver are heavily dependent on the local policy of the - security-aware recursive name server, so as a practical matter there - may be little practical value to checking the status of the AD bit - except perhaps as a debugging aid. In any case, a security-aware - stub resolver MUST NOT place any reliance on signature validation - allegedly performed on its behalf except when the security-aware stub - resolver obtained the data in question from a trusted security-aware - - - -Arends, et al. Expires August 16, 2004 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - recursive name server via a secure channel. - - A validating security-aware stub resolver SHOULD NOT examine the - setting of the AD bit in response messages, since, by definition, the - stub resolver performs its own signature validation regardless of the - setting of the AD bit. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 25] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -5. Authenticating DNS Responses - - In order to use DNSSEC RRs for authentication, a security-aware - resolver requires preconfigured knowledge of at least one - authenticated DNSKEY or DS RR. The process for obtaining and - authenticating this initial DNSKEY or DS RR is achieved via some - external mechanism. For example, a resolver could use some off-line - authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR - that identifies and authenticates a zone's DNSKEY RR. The remainder - of this section assumes that the resolver has somehow obtained an - initial set of authenticated DNSKEY RRs. - - An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY - RRset. To authenticate an apex DNSKEY RRset using an initial key, - the resolver MUST: - - 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag - (DNSKEY RDATA bit 7) set to one. - - 2. Verify that there is some RRSIG RR that covers the apex DNSKEY - RRset, and that the combination of the RRSIG RR and the initial - DNSKEY RR authenticates the DNSKEY RRset. The process for using - an RRSIG RR to authenticate an RRset is described in Section 5.3. - - Once the resolver has authenticated the apex DNSKEY RRset using an - initial DNSKEY RR, delegations from that zone can be authenticated - using DS RRs. This allows a resolver to start from an initial key, - and use DS RRsets to proceed recursively down the DNS tree obtaining - other apex DNSKEY RRsets. If the resolver were preconfigured with a - root DNSKEY RR, and if every delegation had a DS RR associated with - it, then the resolver could obtain and validate any apex DNSKEY - RRset. The process of using DS RRs to authenticate referrals is - described in Section 5.2. - - Once the resolver has authenticated a zone's apex DNSKEY RRset, - Section 5.3 shows how the resolver can use DNSKEY RRs in the apex - DNSKEY RRset and RRSIG RRs from the zone to authenticate any other - RRsets in the zone. Section 5.4 shows how the resolver can use - authenticated NSEC RRsets from the zone to prove that an RRset is not - present in the zone. - - When a resolver indicates support for DNSSEC (by setting the DO bit), - a security-aware name server should attempt to provide the necessary - DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). - However, a security-aware resolver may still receive a response that - that lacks the appropriate DNSSEC RRs, whether due to configuration - issues such as a security-oblivious recursive name server that - - - -Arends, et al. Expires August 16, 2004 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - accidentally interfere with DNSSEC RRs or due to a deliberate attack - in which an adversary forges a response, strips DNSSEC RRs from a - response, or modifies a query so that DNSSEC RRs appear not to be - requested. The absence of DNSSEC data in a response MUST NOT by - itself be taken as an indication that no authentication information - exists. - - A resolver SHOULD expect authentication information from signed - zones. A resolver SHOULD believe that a zone is signed if the - resolver has been configured with public key information for the - zone, or if the zone's parent is signed and the delegation from the - parent contains a DS RRset. - -5.1 Special Considerations for Islands of Security - - Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed - zones for which it is not possible to construct an authentication - chain to the zone from its parent. Validating signatures within an - island of security requires the validator to have some other means of - obtaining an initial authenticated zone key for the island. If a - validator cannot obtain such a key, it will have to choose whether to - accept the unvalidated responses or not based on local policy. - - All the normal processes for validating responses apply to islands of - security. The only difference between normal validation and - validation within an island of security is in how the validator - obtains a starting point for the authentication chain. - -5.2 Authenticating Referrals - - Once the apex DNSKEY RRset for a signed parent zone has been - authenticated, DS RRsets can be used to authenticate the delegation - to a signed child zone. A DS RR identifies a DNSKEY RR in the child - zone's apex DNSKEY RRset, and contains a cryptographic digest of the - child zone's DNSKEY RR. A strong cryptographic digest algorithm - ensures that an adversary can not easily generate a DNSKEY RR that - matches the digest. Thus, authenticating the digest allows a - resolver to authenticate the matching DNSKEY RR. The resolver can - then use this child DNSKEY RR to authenticate the entire child apex - DNSKEY RRset. - - Given a DS RR for a delegation, the child zone's apex DNSKEY RRset - can be authenticated if all of the following hold: - - o The DS RR has been authenticated using some DNSKEY RR in the - parent's apex DNSKEY RRset (see Section 5.3); - - o The Algorithm and Key Tag in the DS RR match the Algorithm field - - - -Arends, et al. Expires August 16, 2004 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset that, when hashed using the digest algorithm specified in - the DS RR's Digest Type field, results in a digest value that - matches the Digest field of the DS RR; and - - o The matching DNSKEY RR in the child zone has the Zone Flag bit set - to one, the corresponding private key has signed the child zone's - apex DNSKEY RRset, and the resulting RRSIG RR authenticates the - child zone's apex DNSKEY RRset. - - If the referral from the parent zone did not contain a DS RRset, the - response should have included a signed NSEC RRset proving that no DS - RRset exists for the delegated name (see Section 3.1.4). A - security-aware resolver MUST query the name servers for the parent - zone for the DS RRset if the referral includes neither a DS RRset nor - a NSEC RRset proving that the DS RRset does not exist (see Section - 4). - - If the resolver authenticates an NSEC RRset that proves that no DS - RRset is present for this zone, then there is no authentication path - leading from the parent to the child. If the resolver has an initial - DNSKEY or DS RR that belongs to the child zone or to any delegation - below the child zone, this initial DNSKEY or DS RR MAY be used to - re-establish an authentication path. If no such initial DNSKEY or DS - RR exists, the resolver can not authenticate RRsets in or below the - child zone. - - Note that, for a signed delegation, there are two NSEC RRs associated - with the delegated name. One NSEC RR resides in the parent zone, and - can be used to prove whether a DS RRset exists for the delegated - name. The second NSEC RR resides in the child zone, and identifies - which RRsets are present at the apex of the child zone. The parent - NSEC RR and child NSEC RR can always be distinguished, since the SOA - bit will be set in the child NSEC RR and clear in the parent NSEC RR. - A security-aware resolver MUST use the parent NSEC RR when attempting - to prove that a DS RRset does not exist. - - If the resolver does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver will not be able to verify - the authentication path to the child zone. In this case, the - resolver SHOULD treat the child zone as if it were unsigned. - -5.3 Authenticating an RRset Using an RRSIG RR - - A resolver can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The resolver first checks the RRSIG - RR to verify that it covers the RRset, has a valid time interval, and - identifies a valid DNSKEY RR. The resolver then constructs the - - - -Arends, et al. Expires August 16, 2004 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - canonical form of the signed data by appending the RRSIG RDATA - (excluding the Signature Field) with the canonical form of the - covered RRset. Finally, resolver uses the public key and signature - to authenticate the signed data. Section 5.3.1, Section 5.3.2, and - Section 5.3.3 describe each step in detail. - -5.3.1 Checking the RRSIG RR Validity - - A security-aware resolver can use an RRSIG RR to authenticate an - RRset if all of the following conditions hold: - - o The RRSIG RR and the RRset MUST have the same owner name and the - same class; - - o The RRSIG RR's Signer's Name field MUST be the name of the zone - that contains the RRset; - - o The RRSIG RR's Type Covered field MUST equal the RRset's type; - - o The number of labels in the RRset owner name MUST be greater than - or equal to the value in the RRSIG RR's Labels field; - - o The resolver's notion of the current time MUST be less than or - equal to the time listed in the RRSIG RR's Expiration field; - - o The resolver's notion of the current time MUST be greater than or - equal to the time listed in the RRSIG RR's Inception field; - - o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST - match the owner name, algorithm, and key tag for some DNSKEY RR in - the zone's apex DNSKEY RRset; - - o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY - RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) - set to one. - - It is possible for more than one DNSKEY RR to match the conditions - above. In this case, the resolver can not predetermine which DNSKEY - RR to use to authenticate the signature, MUST try each matching - DNSKEY RR until the resolver has either validated the signature or - has run out of matching public keys to try. - - Note that this authentication process is only meaningful if the - resolver authenticates the DNSKEY RR before using it to validate - signatures. The matching DNSKEY RR is considered to be authentic if: - - o The apex DNSKEY RRset containing the DNSKEY RR is considered - authentic; or - - - -Arends, et al. Expires August 16, 2004 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, - and the DNSKEY RR either matches an authenticated DS RR from the - parent zone or matches a DS RR or DNSKEY RR that the resolver has - been preconfigured to believe to be authentic. - - -5.3.2 Reconstructing the Signed Data - - Once the RRSIG RR has met the validity requirements described in - Section 5.3.1, the resolver needs to reconstruct the original signed - data. The original signed data includes RRSIG RDATA (excluding the - Signature field) and the canonical form of the RRset. Aside from - being ordered, the canonical form of the RRset might also differ from - the received RRset due to DNS name compression, decremented TTLs, or - wildcard expansion. The resolver should use the following to - reconstruct the original signed data: - - signed_data = RRSIG_RDATA | RR(1) | RR(2)... where - - "|" denotes concatenation - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signature field excluded and the Signer's Name - in canonical form. - - RR(i) = name | class | type | OrigTTL | RDATA length | RDATA - - name is calculated according to the function below - - class is the RRset's class - - type is the RRset type and all RRs in the class - - OrigTTL is the value from the RRSIG Original TTL field - - All names in the RDATA field are in canonical form - - The set of all RR(i) is sorted into canonical order. - - To calculate the name: - let rrsig_labels = the value of the RRSIG Labels field - - let fqdn = RRset's fully qualified domain name in - canonical form - - let fqdn_labels = Label count of the fqdn above. - - if rrsig_labels = fqdn_labels, - - - -Arends, et al. Expires August 16, 2004 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - name = fqdn - - if rrsig_labels < fqdn_labels, - name = "*." | the rightmost rrsig_label labels of the - fqdn - - if rrsig_labels > fqdn_labels - the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this - RRset. - - The canonical forms for names and RRsets are defined in - [I-D.ietf-dnsext-dnssec-records]. - - NSEC RRsets at a delegation boundary require special processing. - There are two distinct NSEC RRsets associated with a signed delegated - name. One NSEC RRset resides in the parent zone, and specifies which - RRset are present at the parent zone. The second NSEC RRset resides - at the child zone, and identifies which RRsets are present at the - apex in the child zone. The parent NSEC RRset and child NSEC RRset - can always be distinguished since only the child NSEC RRs will - specify an SOA RRset exists at the name. When reconstructing the - original NSEC RRset for the delegation from the parent zone, the NSEC - RRs MUST NOT be combined with NSEC RRs from the child zone, and when - reconstructing the original NSEC RRset for the apex of the child - zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent - zone. - - Note also that each of the two NSEC RRsets at a delegation point has - a corresponding RRSIG RR with an owner name matching the delegated - name, and each of these RRSIG RRs is authoritative data associated - with the same zone that contains the corresponding NSEC RRset. If - necessary, a resolver can tell these RRSIG RRs apart by checking the - Signer's Name field. - -5.3.3 Checking the Signature - - Once the resolver has validated the RRSIG RR as described in Section - 5.3.1 and reconstructed the original signed data as described in - Section 5.3.2, the resolver can attempt to use the cryptographic - signature to authenticate the signed data, and thus (finally!) - authenticate the RRset. - - The Algorithm field in the RRSIG RR identifies the cryptographic - algorithm used to generate the signature. The signature itself is - contained in the Signature field of the RRSIG RDATA, and the public - key used to verify the signature is contained in the Public Key field - of the matching DNSKEY RR(s) (found in Section 5.3.1). - - - -Arends, et al. Expires August 16, 2004 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types, - and provides pointers to the documents that define each algorithm's - use. - - Note that it is possible for more than one DNSKEY RR to match the - conditions in Section 5.3.1. In this case, the resolver can only - determine which DNSKEY RR by trying each matching public key until - the resolver either succeeds in validating the signature or runs out - of keys to try. - - If the Labels field of the RRSIG RR is not equal to the number of - labels in the RRset's fully qualified owner name, then the RRset is - either invalid or the result of wildcard expansion. The resolver - MUST verify that wildcard expansion was applied properly before - considering the RRset to be authentic. Section 5.3.4 describes how - to determine whether a wildcard was applied properly. - - If other RRSIG RRs also cover this RRset, the local resolver security - policy determines whether the resolver also needs to test these RRSIG - RRs, and determines how to resolve conflicts if these RRSIG RRs lead - to differing results. - - If the resolver accepts the RRset as authentic, the resolver MUST set - the TTL of the RRSIG RR and each RR in the authenticated RRset to a - value no greater than the minimum of: - - o The RRset's TTL as received in the response; - - o The RRSIG RR's TTL as received in the response; and - - o The value in the RRSIG RR's Original TTL field. - - -5.3.4 Authenticating A Wildcard Expanded RRset Positive Response - - If the number of labels in an RRset's owner name is greater than the - Labels field of the covering RRSIG RR, then the RRset and its - covering RRSIG RR were created as a result of wildcard expansion. - Once the resolver has verified the signature as described in Section - 5.3, the resolver must take additional steps to verify the - non-existence of an exact match or closer wildcard match for the - query. Section 5.4 discusses these steps. - - Note that the response received by the resolver should include all - NSEC RRs needed to authenticate the response (see Section 3.1.3). - -5.4 Authenticated Denial of Existence - - - - -Arends, et al. Expires August 16, 2004 [Page 32] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - A resolver can use authenticated NSEC RRs to prove that an RRset is - not present in a signed zone. Security-aware name servers should - automatically include any necessary NSEC RRs for signed zones in - their responses to security-aware resolvers. - - Security-aware resolvers MUST first authenticate NSEC RRsets - according to the standard RRset authentication rules described in - Section 5.3, then apply the NSEC RRsets as follows: - - o If the requested RR name matches the owner name of an - authenticated NSEC RR, then the NSEC RR's type bit map field lists - all RR types present at that owner name, and a resolver can prove - that the requested RR type does not exist by checking for the RR - type in the bit map. If the number of labels in an authenticated - NSEC RR's owner name equals the Labels field of the covering RRSIG - RR, then the existence of the NSEC RR proves that wildcard - expansion could not have been used to match the request. - - o If the requested RR name would appear after an authenticated NSEC - RR's owner name and before the name listed in that NSEC RR's Next - Domain Name field according to the canonical DNS name order - defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with - the requested name exist in the zone. However, it is possible - that a wildcard could be used to match the requested RR owner name - and type, so proving that the requested RRset does not exist also - requires proving that no possible wildcard RRset exists that could - have been used to generate a positive response. - - To prove non-existence of an RRset, the resolver must be able to - verify both that the queried RRset does not exist and that no - relevant wildcard RRset exists. Proving this may require more than - one NSEC RRset from the zone. If the complete set of necessary NSEC - RRsets is not present in a response (perhaps due to message - truncation), then a security-aware resolver MUST resend the query in - order to attempt to obtain the full collection of NSEC RRs necessary - to verify non-existence of the requested RRset. As with all DNS - operations, however, the resolver MUST bound the work it puts into - answering any particular query. - - Since a verified NSEC RR proves the existence of both itself and its - corresponding RRSIG RR, a verifier MUST ignore the settings of the - NSEC and RRSIG bits in an NSEC RR. - -5.5 Authentication Example - - Appendix C shows an example the authentication process. - - - - - -Arends, et al. Expires August 16, 2004 [Page 33] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -6. IANA Considerations - - [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA - considerations introduced by DNSSEC. The additional IANA - considerations discussed in this document: - - [RFC2535] reserved the CD and AD bits in the message header. The - meaning of the AD bit was redefined in [RFC3655] and the meaning of - both the CD and AD bit are restated in this document. No new bits in - the DNS message header are defined in this document. - - [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit - and defined its use. The use is restated but not altered in this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 34] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -7. Security Considerations - - This document describes how the DNS security extensions use public - key cryptography to sign and authenticate DNS resource record sets. - Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general - security considerations related to DNSSEC; see - [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the - DNSSEC resource record types. - - An active attacker who can set the CD bit in a DNS query message or - the AD bit in a DNS response message can use these bits to defeat the - protection which DNSSEC attempts to provide to security-oblivious - recursive-mode resolvers. For this reason, use of these control bits - by a security-aware recursive-mode resolver requires a secure - channel. See Section 3.2.2 and Section 4.8 for further discussion. - - The protocol described in this document attempts to extend the - benefits of DNSSEC to security-oblivious stub resolvers. However, - since recovery from validation failures is likely to be specific to - particular applications, the facilities that DNSSEC provides for stub - resolvers may prove inadequate. Operators of security-aware - recursive name servers will need to pay close attention to the - behavior of the applications which use their services when choosing a - local validation policy; failure to do so could easily result in the - recursive name server accidently denying service to the clients it is - intended to support. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 35] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -8. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 36] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-09 (work in progress), - February 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-07 (work in progress), - February 2004. - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Informative References - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [I-D.ietf-dnsext-wcard-clarify] - Halley, B. and E. Lewis, "Clarifying the Role of Wild Card - Domains in the Domain Name System", - draft-ietf-dnsext-wcard-clarify-02 (work in progress), - September 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - - - - -Arends, et al. Expires August 16, 2004 [Page 38] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 39] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix A. Signed Zone Example - - The following example shows a (small) complete signed zone. - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18 - 7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe - IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+ - M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q - 7wxkDWyzgasGiMNIKgYrm9vXz04= ) - 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - 3600 DNSKEY 256 3 5 ( - AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH - UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV - fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv - BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO - - - -Arends, et al. Expires August 16, 2004 [Page 40] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q== - ) - 3600 DNSKEY 257 3 5 ( - AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U - Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv - klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE - 2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT - nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ== - ) - 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU - pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5 - YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc - tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG - PjJstq6fvRq8kX7TPJcljUmDFKM= ) - 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( - 20031216201552 60717 example. - EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/ - C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK - L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY - J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34 - Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 48327 5 1 ( - DFEB5E00E71A4DED5CABBBD7F15F24871983 - CAB7 ) - 3600 RRSIG DS 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ - hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb - rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c - ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC - 0yfe2uolEkeegjesDZuF+fC61Eg= ) - 3600 NSEC ai.example. NS DS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb - RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1 - 3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O - ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf - YgfAHJEJJj7K88QbKEK4/Je1hyk= ) - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - ai.example. 3600 IN A 192.0.2.9 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - - - -Arends, et al. Expires August 16, 2004 [Page 41] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 - jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c - Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk - OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A - sWifTxvcG5hv+A6TOd0O2xJYRik= ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C - hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2 - KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2 - Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92 - xo9NLoltg0GuwggZM240pRoTwO8= ) - 3600 AAAA 2001:db8::f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 - 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ - G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI - A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI - zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) - 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE - ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y - ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU - 4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR - ovChG5Ih3TOa8Qnch4IJQVfSFNU= ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - 3600 NSEC ns1.example. NS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - ns1.example. 3600 IN A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 - CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs - RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf - +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa - - - -Arends, et al. Expires August 16, 2004 [Page 42] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) - 3600 NSEC ns2.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ - sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 - eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA - s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj - I2A5W86mMEbSgEF/pZHX/wi5FJI= ) - ns2.example. 3600 IN A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL - xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK - HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht - sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG - wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) - 3600 NSEC *.w.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb - IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b - f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J - aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl - yCup5bk/Dr47eU2/6+lqrBTOV8Q= ) - *.w.example. 3600 IN MX 1 ai.example. - 3600 RRSIG MX 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg - OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns - Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA - n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK - 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) - 3600 NSEC x.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr - f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 - 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK - /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW - ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) - x.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW - ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m - 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY - MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv - - - -Arends, et al. Expires August 16, 2004 [Page 43] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - btznHMFDIbtuw/tAX7xXH2pDDHY= ) - 3600 NSEC x.y.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia - CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA - EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA - aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT - 3lMXiX4KNWUhB87q/pT/5z+xrqY= ) - x.y.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD - v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE - unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK - Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk - Iykd5UmaTO5j4LlRnAvF8Z1m9/k= ) - 3600 NSEC xx.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - xx.example. 3600 IN A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap - tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq - iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS - KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G - 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw - p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA - gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/ - pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp - EDXT07qFXtGntvBSpF9uQbEub6Y= ) - 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 - dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD - mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg - CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z - - - -Arends, et al. Expires August 16, 2004 [Page 44] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - D4ZubIon0XGe9fIjLnmb3pX/FUk= ) - 3600 NSEC example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn - uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE - NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a - 1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187 - sSNF3PAC0HPadh7SdHmXlFQtQ44= ) - - The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA - Flags indicate that each of these DNSKEY RRs is a zone key. One of - these DNSKEY RRs also has the SEP flag set and has been used to sign - the apex DNSKEY RRset; this is the key which should be hashed to - generate a DS record to be inserted into the parent zone. The other - DNSKEY is used to sign all the other RRsets in the zone. - - The zone includes a wildcard entry "*.w.example". Note that the name - "*.w.example" is used in constructing NSEC chains, and that the RRSIG - covering the "*.w.example" MX RRset has a label count of 2. - - The zone also includes two delegations. The delegation to - "b.example" includes an NS RRset, glue address records, and an NSEC - RR; note that only the NSEC RRset is signed. The delegation to - "a.example" provides a DS RR; note that only the NSEC and DS RRsets - are signed. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 45] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix B. Example Responses - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1 Answer - - A successful query to an authoritative server. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - x.w.example. IN MX - - ;; Answer - x.w.example. 3600 IN MX 1 xx.example. - x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW - ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m - 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY - MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv - btznHMFDIbtuw/tAX7xXH2pDDHY= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap - tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq - iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS - KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G - 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) - xx.example. 3600 AAAA 2001:db8::f00:baaa - xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 - - - -Arends, et al. Expires August 16, 2004 [Page 46] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD - mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg - CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z - D4ZubIon0XGe9fIjLnmb3pX/FUk= ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 - CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs - RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf - +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa - WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL - xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK - HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht - sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG - wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) - - -B.2 Name Error - - An authoritative name error. The NSEC RRs prove that the name does - not exist and that no covering wildcard exists. - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - ml.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - - - -Arends, et al. Expires August 16, 2004 [Page 47] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - - ;; Additional - ;; (empty) - - -B.3 No Data Error - - A "NODATA" response. The NSEC RR proves that the name exists and - that the requested RR type does not. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - - - -Arends, et al. Expires August 16, 2004 [Page 48] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC - ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ - sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 - eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA - s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj - I2A5W86mMEbSgEF/pZHX/wi5FJI= ) - - ;; Additional - ;; (empty) - - -B.4 Referral to Signed Zone - - Referral to a signed zone. The DS RR contains the data which the - resolver will need to validate the corresponding DNSKEY RR in the - child zone's apex. - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.a.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - a.example. 3600 IN NS ns1.a.example. - a.example. 3600 IN NS ns2.a.example. - a.example. 3600 DS 48327 5 1 ( - DFEB5E00E71A4DED5CABBBD7F15F24871983 - CAB7 ) - a.example. 3600 RRSIG DS 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ - hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb - rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c - ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC - 0yfe2uolEkeegjesDZuF+fC61Eg= ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - - - - -Arends, et al. Expires August 16, 2004 [Page 49] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -B.5 Referral to Unsigned Zone - - Referral to an unsigned zone. The NSEC RR proves that no DS RR for - this delegation exists in the parent zone. - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.b.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - b.example. 3600 IN NS ns1.b.example. - b.example. 3600 IN NS ns2.b.example. - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - - -B.6 Wildcard Expansion - - A successful query which was answered via wildcard expansion. The - label count in the answer's RRSIG RR indicates that a wildcard RRset - was expanded to produce this response, and the NSEC RR proves that no - closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. 3600 IN MX 1 ai.example. - a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg - OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns - - - -Arends, et al. Expires August 16, 2004 [Page 50] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA - n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK - 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 - jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c - Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk - OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A - sWifTxvcG5hv+A6TOd0O2xJYRik= ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 - 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ - G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI - A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI - zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) - - -B.7 Wildcard No Data Error - - A "NODATA" response for a name covered by a wildcard. The NSEC RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - - - -Arends, et al. Expires August 16, 2004 [Page 51] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC - *.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr - f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 - 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK - /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW - ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) - - ;; Additional - ;; (empty) - - -B.8 DS Child Zone No Data Error - - A "NODATA" response for a QTYPE=DS query which was mistakenly sent to - a name server for the child zone. - - - -Arends, et al. Expires August 16, 2004 [Page 52] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - - ;; Additional - ;; (empty) - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 53] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix C. Authentication Examples - - The examples in this section show how the response messages in - Appendix B are authenticated. - -C.1 Authenticating An Answer - - The query in section Appendix B.1 returned an MX RRset for - "x.w.example.com". The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 41681. - The resolver needs the corresponding DNSKEY RR in order to - authenticate this answer. The discussion below describes how a - resolver might obtain this DNSKEY RR. - - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 3 indicates the answer was - not the result of wildcard expansion. The "x.w.example.com" MX RRset - is placed in canonical form and, assuming the current time falls - between the signature inception and expiration dates, the signature - is authenticated. - -C.1.1 Authenticating the example DNSKEY RR - - This example shows the logical authentication process that starts - from the a preconfigured root DNSKEY (or DS RR) and moves down the - tree to authenticate the desired "example" DNSKEY RR. Note the - logical order is presented for clarity and an implementation may - choose to construct the authentication as referrals are received or - may choose to construct the authentication chain only after all - RRsets have been obtained, or in any other combination it sees fit. - The example here demonstrates only the logical process and does not - dictate any implementation rules. - - We assume the resolver starts with an preconfigured DNSKEY RR for the - root zone (or a preconfigured DS RR for the root zone). The resolver - checks this preconfigured DNSKEY RR is present in the root DNSKEY - RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset), - this DNSKEY RR has signed the root DNSKEY RRset and the signature - lifetime is valid. If all these conditions are met, all keys in the - DNSKEY RRset are considered authenticated. The resolver then uses - one (or more) of the root DNSKEY RRs to authenticate the "example" DS - RRset. Note the resolver may need to query the root zone to obtain - the root DNSKEY RRset and/or "example" DS RRset. - - Once the DS RRset has been authenticated using the root DNSKEY, the - resolver checks the "example" DNSKEY RRset for some "example" DNSKEY - RR that matches one of the authenticated "example" DS RRs. If such a - - - -Arends, et al. Expires August 16, 2004 [Page 54] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - matching "example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the "example" - DNSKEY RRset are considered authenticated. - - Finally the resolver checks that some DNSKEY RR in the "example" - DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This - DNSKEY is used to authenticated the RRSIG included in the response. - If multiple "example" DNSKEY RRs have algorithm 5 and key tag of - 41681, then each DNSKEY RR is tried and the answer is authenticated - if either DNSKEY RR validates the signature as described above. - -C.2 Name Error - - The query in section Appendix B.2 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. The NSEC RRs are - authenticated in a manner identical to that of the MX RRset discussed - above. - -C.3 No Data Error - - The query in section Appendix B.3 returned an NSEC RR that proves the - requested name exists, but the requested RR type does not exist. The - negative reply is authenticated by verifying the NSEC RR. The NSEC - RR is authenticated in a manner identical to that of the MX RRset - discussed above. - -C.4 Referral to Signed Zone - - The query in section Appendix B.4 returned a referral to the signed - "a.example." zone. The DS RR is authenticated in a manner identical - to that of the MX RRset discussed above. This DS RR is used to - authenticate the "a.example" DNSKEY RRset. - - Once the "a.example" DS RRset has been authenticated using the - "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset - for some "a.example" DNSKEY RR that matches the DS RR. If such a - matching "a.example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "a.example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the - "a.example" DNSKEY RRset are considered authenticated. - -C.5 Referral to Unsigned Zone - - The query in section Appendix B.5 returned a referral to an unsigned - "b.example." zone. The NSEC proves that no authentication leads from - "example" to "b.example" and the NSEC RR is authenticated in a manner - - - -Arends, et al. Expires August 16, 2004 [Page 55] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - identical to that of the MX RRset discussed above. - -C.6 Wildcard Expansion - - The query in section Appendix B.6 returned an answer that was - produced as a result of wildcard expansion. The RRset expanded as - the similar to The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 41681. - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 2 indicates the answer the - result of wildcard expansion since the "a.z.w.example" name contains - 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", - the MX RRset is placed in canonical form and, assuming the current - time falls between the signature inception and expiration dates, the - signature is authenticated. - - The NSEC proves that no closer match (exact or closer wildcard) could - have been used to answer this query and the NSEC RR must also be - authenticated before the answer is considered valid. - -C.7 Wildcard No Data Error - - The query in section Appendix B.7 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. - -C.8 DS Child Zone No Data Error - - The query in section Appendix B.8 returned NSEC RRs that shows the - requested was answered by a child server ("example" server). The - NSEC RR indicates the presence of an SOA RR, showing the answer is - from the child . Queries for the "example" DS RRset should be sent - to the parent servers ("root" servers). - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 56] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires August 16, 2004 [Page 57] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 58] - - + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: November 15, 2004 M. Larson + VeriSign + R. Austein + ISC + D. Massey + USC/ISI + S. Rose + NIST + May 17, 2004 + + + Protocol Modifications for the DNS Security Extensions + draft-ietf-dnsext-dnssec-protocol-06 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents which describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications which + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + + + +Arends, et al. Expires November 15, 2004 [Page 1] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + defines the concept of a signed zone, along with the requirements for + serving and resolving using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . 4 + 1.3.2 Technical Changes or Corrections . . . . . . . . . . . 4 + 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . 5 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 6 + 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 6 + 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 7 + 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 8 + 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8 + 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . 9 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 11 + 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 11 + 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 12 + 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 12 + 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 15 + 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 16 + 3.1.6 The AD and CD Bits in an Authoritative Response . . . 17 + 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 + 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 19 + 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 . . . . . . . . . . . . . . . . . 21 + 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22 + 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 + + + +Arends, et al. Expires November 15, 2004 [Page 2] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + 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 Using an RRSIG RR . . . . . . . . 27 + 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 + 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 + 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 + 5.3.4 Authenticating A Wildcard Expanded RRset Positive + Response . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 + 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 + 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 + B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 + B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 + C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 + C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 + C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 + C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 + C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 + C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 + C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 + C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 + C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 + Intellectual Property and Copyright Statements . . . . . . . . 57 + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 3] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications which add data origin + authentication and data integrity to the DNS. This document defines + the DNSSEC protocol modifications. Section 2 of this document defines + the concept of a signed zone and lists the requirements for zone + signing. Section 3 describes the modifications to authoritative name + server behavior necessary to handle signed zones. Section 4 describes + the behavior of entities which include security-aware resolver + functions. Finally, Section 5 defines how to use DNSSEC RRs to + authenticate a response. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in [RFC1034] and [RFC1035]. + + This document is part of a family of documents that define DNSSEC. + An introduction to DNSSEC and definition of common terms can be found + in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC + resource records can be found in [I-D.ietf-dnsext-dnssec-records]. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. [RFC2119]. + +1.3 Editors' Notes + +1.3.1 Open Technical Issues + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + + + + +Arends, et al. Expires November 15, 2004 [Page 4] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +1.3.3 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 5] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to + the rules specified in Section 2.1, Section 2.2, Section 2.3 and + Section 2.4, respectively. A zone that does not include these + records according to the rules in this section is an unsigned zone. + + DNSSEC requires a change to the definition of the CNAME resource + record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG + and NSEC RRs to appear at the same owner name as a CNAME RR. + +2.1 Including DNSKEY RRs in a Zone + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with + the public component stored in the zone. A zone key DNSKEY RR MUST + have the Zone Key bit of the flags RDATA field set to one -- see + Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys + associated with other DNS operations MAY be stored in DNSKEY RRs that + are not marked as zone keys but MUST NOT be used to verify RRSIGs. + + If the zone is delegated and does not wish to act as an island of + security, the zone MUST have at least one DNSKEY RR at the apex to + act as a secure entry point into the zone. This DNSKEY would then be + used to generate a DS RR at the delegating parent (see + [I-D.ietf-dnsext-dnssec-records]). + + DNSKEY RRs MUST NOT appear at delegation points. + +2.2 Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone, there MUST be at least + one RRSIG record that meets all of the following requirements: + o The RRSIG owner name is equal to the RRset owner name; + o The RRSIG class is equal to the RRset class; + o The RRSIG Type Covered field is equal to the RRset type; + o The RRSIG Original TTL field is equal to the TTL of the RRset; + o The RRSIG RR's TTL is equal to the TTL of the RRset; + o The RRSIG Labels field is equal to the number of labels in the + RRset owner name, not counting the null root label and not + counting the leftmost label if it is a wildcard; + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset; and + o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key DNSKEY record at the zone apex. + + + +Arends, et al. Expires November 15, 2004 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + The process for constructing the RRSIG RR for a given RRset is + described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have + multiple RRSIG RRs associated with it. + + An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR + would add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated with + delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset + 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 + + Each owner name in the zone which has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + process for constructing the NSEC RR for a given name is described in + [I-D.ietf-dnsext-dnssec-records]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner names nodes which were + not the owner name of any RRset before the zone was signed. The main + reasons for this are a desire for namespace consistency between + signed and unsigned versions of the same zone and a desire to reduce + the risk of response inconsistency in security oblivious recursive + name servers. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + The difference between the set of owner names that require RRSIG + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + + + +Arends, et al. Expires November 15, 2004 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + signed zone to its children. Neither NSEC nor RRSIG records are + present (in the parent zone) at the owner names of glue address + RRsets. Note, however, that this distinction is for the most part is + only visible during the zone signing process, because NSEC RRsets are + authoritative data, and are therefore signed, thus any owner name + which has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set to + 1; bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be set to 0. + +2.4 Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR which is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (i.e., the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5 Changes to the CNAME Resource Record. + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed. Other types + MUST NOT be present at that name. + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + + + +Arends, et al. Expires November 15, 2004 [Page 8] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +2.6 Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 9] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +3. Serving + + This section describes the behavior of entities that include + security-aware name server functions. In many cases such functions + will be part of a security-aware recursive name server, but a + security-aware authoritative name server has some of the same + requirements. Functions specific to security-aware recursive name + servers are described in Section 3.2; functions specific to + authoritative servers are described in Section 3.1. + + The terms "SNAME", "SCLASS", and "STYPE" in the following discussion + are as used in [RFC1034]. + + A security-aware name server MUST support the EDNS0 [RFC2671] message + size extension, MUST support a message size of at least 1220 octets, + and SHOULD support a message size of 4000 octets [RFC3226]. + + A security-aware name server that receives a DNS query that does not + include the EDNS OPT pseudo-RR or that has the DO bit set to zero + MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other + RRset, and MUST NOT perform any of the additional processing + described below. Since the DS RR type has the peculiar property of + only existing in the parent zone at delegation points, DS RRs always + require some special processing, as described in Section 3.1.4.1. + + Security aware name servers that receive queries for security RR + types which match the content of more than one zone that it serves + (e.g. NSEC and RRSIG RRs above and below a delegation point where the + server is authoritative for both zones) are encouraged to 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 (i.e. no records) + o Some other response + o An error + As long as the response is always consistent for each query to the + name server. + + DNSSEC allocates two new bits in the DNS message header: the CD + (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + is controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Section 3.1.6, + Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details + on the behavior of these bits. + + + + +Arends, et al. Expires November 15, 2004 [Page 10] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + A security aware name server which synthesizes CNAME RRs from DNAME + RRs as described in [RFC2672] SHOULD NOT generate signatures for the + synthesized CNAME RRs. + +3.1 Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS [RFC2671] OPT + pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative + name server for a signed zone MUST include additional RRSIG, NSEC, + and DS RRs according to the following rules: + o RRSIG RRs that can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1; + o NSEC RRs that can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.1.3; + o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST + be included in referrals automatically according to the rules in + Section 3.1.4. + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1 Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set to one, a + security-aware authoritative name server SHOULD attempt to send RRSIG + RRs that a security-aware resolver can use to authenticate the RRsets + in the response. 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 + of these RRSIG RRs, the name server MUST set the TC bit. + o When placing a signed RRset in the Authority section, the name + server MUST also place its RRSIG RRs in the Authority section. + The RRSIG RRs have a higher priority for inclusion than any other + RRsets that may need to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + o When placing a signed RRset in the Additional section, the name + server MUST also place its RRSIG RRs in the Additional section. + If space does not permit inclusion of both the RRset and its + associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If + this happens, the name server MUST NOT set the TC bit solely + because these RRSIG RRs didn't fit. + + + + + +Arends, et al. Expires November 15, 2004 [Page 11] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +3.1.2 Including DNSKEY RRs In a Response + + When responding to a query that has the DO bit set to one and that + requests the SOA or NS RRs at the apex of a signed zone, a + security-aware authoritative name server for that zone MAY return the + zone apex DNSKEY RRset in the Additional section. In this situation, + the DNSKEY RRset and associated RRSIG RRs have lower priority than + any other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + +3.1.3 Including NSEC RRs In a Response + + When responding to a query that has the DO bit set to one, a + security-aware authoritative name server for a signed zone MUST + include NSEC RRs in each of the following cases: + + No Data: The zone contains RRsets that exactly match , + but does not contain any RRsets that exactly match . + + Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match but does contain an RRset that matches + via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match , does contain one or more RRsets that match + via wildcard name expansion, but does not contain + any RRsets that match via wildcard name + expansion. + + In each of these cases, the name server includes NSEC RRs in the + response to prove that an exact match for was + not present in the zone and that the response that the name server is + returning is correct given the data that are in the zone. + +3.1.3.1 Including NSEC RRs: No Data Response + + If the zone contains RRsets matching but contains no + RRset matching , then the name server MUST + include the NSEC RR for along with its associated + + + +Arends, et al. Expires November 15, 2004 [Page 12] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + RRSIG RR(s) in the Authority section of the response (see Section + 3.1.1). If space does not permit inclusion of the NSEC RR or its + associated RRSIG RR(s), the name server MUST set the TC bit (see + Section 3.1.1). + + Since the search name exists, wildcard name expansion does not apply + to this query, and a single signed NSEC RR suffices to prove the + requested RR type does not exist. + +3.1.3.2 Including NSEC RRs: Name Error Response + + If the zone does not contain any RRsets matching + either exactly or via wildcard name expansion, then the name server + MUST include the following NSEC RRs in the Authority section, along + with their associated RRSIG RRs: + o An NSEC RR proving that there is no exact match for ; and + o An NSEC RR proving that the zone contains no RRsets that would + match via wildcard name expansion. + + In some cases a single NSEC RR may prove both of these points, in + that case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + Note that this form of response includes cases in which SNAME + corresponds to an empty non-terminal name within the zone (a name + which is not the owner name for any RRset but which is the parent + name of one or more RRsets). + +3.1.3.3 Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets which exactly match but does contain an RRset which matches via wildcard name expansion, the name server MUST include the + wildcard-expanded answer and the corresponding wildcard-expanded + RRSIG RRs in the Answer section, and MUST include in the Authority + section an NSEC RR and associated RRSIG RR(s) proving that the zone + does not contain a closer match for . If space does + not permit inclusion of the answer, NSEC and RRSIG RRs, the name + server MUST set the TC bit (see Section 3.1.1). + + + + +Arends, et al. Expires November 15, 2004 [Page 13] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +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 . + + In some cases a single NSEC RR may prove both of these points, in + which case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5 Finding The Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server needs to locate an NSEC RR + which proves that 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. + + 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 + 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 + extra step. More precisely, the algorithm for finding the NSEC + proving that no RRsets exist with the applicable wildcard name is + + + +Arends, et al. Expires November 15, 2004 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + 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 + authoritative name server has already checked for the presence of + precisely this wildcard name as part of step (1)(c) of the normal + lookup algorithm described in Section 4.3.2 of [RFC1034]. + +3.1.4 Including DS RRs In a Response + + When responding to a query which has the DO bit set to one, a + security-aware authoritative name server returning a referral + includes DNSSEC data along with the NS RRset. + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. The name server MUST + place the NS RRset before the DS RRset and its associated RRSIG + RR(s). + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR which proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages, and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1 Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, since the name server for + the child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + + + +Arends, et al. Expires November 15, 2004 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + o the name server has received a query for the DS RRset at a zone + cut; and + o the name server is authoritative for the child zone; and + o the name server is not authoritative for the parent zone; and + o the name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all of the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5 Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation. + + 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 + its own zone validation MUST NOT selectively reject some RRs and + accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + of the zone in which the RRset is authoritative data: in the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut, and + + + +Arends, et al. Expires November 15, 2004 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, since the NSEC RR in the child zone's apex will always + indicate the presence of the child zone's SOA RR while the parental + NSEC RR at the zone cut will never indicate the presence of an SOA + RR. As with any other authoritative RRs, NSEC RRs MUST be included + in zone transfers of the zone in which they are authoritative data: + the parental NSEC RR at a zone cut MUST be included zone transfers of + the parent zone, while the NSEC at the zone apex of the child zone + MUST be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut, + and are authoritative in whichever zone contains the authoritative + RRset for which the RRSIG RR provides the signature. That is, the + RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, while the RRSIG for any RRset in + the child zone's apex will be authoritative in the child zone. As + with any other authoritative RRs, RRSIG RRs MUST be included in zone + transfers of the zone in which they are authoritative data. + +3.1.6 The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed for use in communication between + security-aware resolvers and security-aware recursive name servers. + These bits are for the most part not relevant to query processing by + 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 + is set to zero. 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 + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation, but the name server + MUST NOT do so unless the name server obtained the authoritative zone + via secure means (such as a secure zone transfer mechanism), and MUST + NOT do so unless this behavior has been configured explicitly. + + A security-aware name server which supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2 Recursive Name Servers + + As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware + + + +Arends, et al. Expires November 15, 2004 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + recursive name server is an entity which acts in both the + security-aware name server and security-aware resolver roles. This + section uses the terms "name server side" and "resolver side" to + refer to the code within a security-aware recursive name server which + implements the security-aware name server role and the code which + implements the security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching which would apply to any security-aware resolver. + +3.2.1 The DO bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response, but MUST + NOT strip any DNSSEC RR types that the initiating query explicitly + requested. + +3.2.2 The CD bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + The name server side of a security-aware recursive name server MUST + pass the sense of the CD bit to the resolver side along with the rest + of an initiating query, so that the resolver side will know whether + or not it is required to verify the response data it returns to the + name server side. If the CD bit is set to one, it indicates that the + originating resolver is willing to perform whatever authentication + its local policy requires, thus the resolver side of the recursive + name server need not perform authentication on the RRsets in the + response. When the CD bit is set to one the recursive name server + SHOULD, if possible, return the requested data to the originating + resolver even if the recursive name server's local authentication + policy would reject the records in question. That is, by setting the + CD bit, the originating resolver has indicated that it takes + responsibility for performing its own authentication, and the + recursive name server should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query which matches an entry in the + resolver side's BAD cache, the name server side's response depends on + + + +Arends, et al. Expires November 15, 2004 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + the sense of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + + 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 + capable of performing its own signature validation from ever seeing + the "bad" data does not help the client. + +3.2.3 The AD bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + authentic. The name server side SHOULD set the AD bit if and only if + the resolver side considers all RRsets in the Answer section and any + relevant negative response RRs in the Authority section to be + authentic. The resolver side MUST follow the procedure described in + Section 5 to determine whether the RRs in question are authentic. + However, for backwards compatibility, a recursive name server MAY set + the AD bit when a response includes unsigned CNAME RRs if those CNAME + RRs demonstrably could have been synthesized from an authentic DNAME + RR which is also included in the response according to the synthesis + rules described in [RFC2672]. + +3.3 Example DNSSEC Responses + + See Appendix B for example response packets. + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 19] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +4. Resolving + + This section describes the behavior of entities that include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1 EDNS Support + + A security-aware resolver MUST include an EDNS [RFC2671] OPT + pseudo-RR with the DO [RFC3225] bit set to one when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + advertise the supported message size using the "sender's UDP payload + size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST + handle fragmented UDP packets correctly regardless of whether any + such fragmented packets were received via IPv4 or IPv6. Please see + [RFC3226] for discussion of these requirements. + +4.2 Signature Verification Support + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5, and MUST apply them to every + received response except when: + o The security-aware resolver is part of a security-aware recursive + name server, and the response is the result of recursion on behalf + of a query received with the CD bit set; + o The response is the result of a query generated directly via some + form of application interface which instructed the security-aware + resolver not to perform validation for this query; or + o Validation for this query has been disabled by local policy. + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + Security aware resolvers MAY query for missing security RRs in an + attempt to perform validation; implementations that choose to do so + must be aware of the fact that the answers received may not be + sufficient to validate the original response. + + When attempting to retrieve missing NSEC RRs which reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + + + +Arends, et al. Expires November 15, 2004 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name; if no NS RRset is present at that name, the + resolver then strips of the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + +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 + 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. + + 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 + RRset. This can occur when the target RRset lies in an unsigned + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + 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. + + 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. + +4.4 Configured Trust Anchors + + A security-aware resolver MUST be capable of being configured with at + + + +Arends, et al. Expires November 15, 2004 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + 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 + reasonably robust mechanism for obtaining such keys when it boots; + examples of such a mechanism would be some form of non-volatile + storage (such as a disk drive) or some form of trusted local network + configuration mechanism. + + Note that trust anchors also covers 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. + +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 + and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. In + most cases the appropriate cache index for the atomic entry will be + the triple , but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double . + +4.6 Handling of the CD and AD bits + + A security-aware resolver MAY set the CD bit in a query to one in + order to indicate that the resolver takes responsibility for + performing whatever authentication its local policy requires on the + RRsets in the response. See Section 3.2 for the effect this bit has + on the behavior of security-aware recursive name servers. + + A security-aware resolver MUST zero the AD bit when composing query + messages to protect against buggy name servers which blindly copy + header bits which they do not understand from the query message to + the response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained using a secure channel or + the resolver was specifically configured to regard the message header + bits without using a secure channel. + +4.7 Caching BAD Data + + While many validation errors will be transient, some are likely to be + more persistent, such as those caused by administrative error + (failure to re-sign a zone, clock skew, and so forth). Since + requerying will not help in these cases, validating resolvers might + + + +Arends, et al. Expires November 15, 2004 [Page 22] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + generate a significant amount of unnecessary DNS traffic as a result + of repeated queries for RRsets with persistent validation failures. + + To prevent such unnecessary DNS traffic, security-aware resolvers MAY + cache data with invalid signatures, with some restrictions. + 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, + 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 + from the BAD cache after the number of times that responses to + queries for that particular have failed to + validate exceeds a threshold value. + + 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 + + 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 + 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 + + 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. + + + + + +Arends, et al. Expires November 15, 2004 [Page 23] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +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. + + A validating security-aware stub resolver MUST set the DO bit, since + otherwise it will not receive the DNSSEC RRs it needs to perform + signature validation. + +4.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 + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + since otherwise the security-aware recursive name server will answer + the query using the name server's local policy, which may prevent the + stub resolver from receiving data which would be acceptable to the + stub resolver's local policy. + +4.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 + 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. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, since, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + +Arends, et al. Expires November 15, 2004 [Page 24] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +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 + 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, + the resolver MUST: + 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag + (DNSKEY RDATA bit 7) set to one. + 2. Verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset using an + initial DNSKEY RR, delegations from that zone can be authenticated + using DS RRs. This allows a resolver to start from an initial key, + and use DS RRsets to proceed recursively down the DNS tree obtaining + other apex DNSKEY RRsets. If the resolver were 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 + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + that lacks the appropriate DNSSEC RRs, whether due to configuration + issues such as an upstream security-oblivious recursive name server + that accidentally interferes with DNSSEC RRs or due to a deliberate + attack in which an adversary forges a response, strips DNSSEC RRs + + + +Arends, et al. Expires November 15, 2004 [Page 25] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + from a response, or modifies a query so that DNSSEC RRs appear not to + be requested. The absence of DNSSEC data in a response MUST NOT by + itself be taken as an indication that no authentication information + exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1 Special Considerations for Islands of Security + + Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed + zones for which it is not possible to construct an authentication + chain to the zone from its parent. Validating signatures within an + island of security requires the validator to have some other means of + obtaining an initial authenticated zone key for the island. If a + validator cannot obtain such a key, it 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 + + Once the apex DNSKEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a DNSKEY RR in the child + zone's apex DNSKEY RRset, and contains a cryptographic digest of the + child zone's DNSKEY RR. A strong cryptographic digest algorithm + ensures that an adversary can not easily generate a DNSKEY RR that + matches the digest. Thus, authenticating the digest allows a + resolver to authenticate the matching DNSKEY RR. The resolver can + then use this child DNSKEY RR to authenticate the entire child apex + DNSKEY RRset. + + Given a DS RR for a delegation, the child zone's apex DNSKEY RRset + can be authenticated if all of the following hold: + o The DS RR has been authenticated using some DNSKEY RR in the + parent's apex DNSKEY RRset (see Section 5.3); + o The Algorithm and Key Tag in the DS RR match the Algorithm field + and the key tag of a DNSKEY RR in the child zone's apex DNSKEY + RRset and, when hashed using the digest algorithm specified in the + DS RR's Digest Type field, results in a digest value that matches + the Digest field of the DS RR; and + + + +Arends, et al. Expires November 15, 2004 [Page 26] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + o The matching DNSKEY RR in the child zone has the Zone Flag bit set + to one, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the validator authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the validator can not authenticate RRsets in or below the + child zone. + + If the validator does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + 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 + can be used to prove whether a DS RRset exists for the delegated + name. The second NSEC RR resides in the child zone, and identifies + which RRsets are present at the apex of the child zone. The parent + NSEC RR and child NSEC RR can always be distinguished, since the SOA + bit will be set in the child NSEC RR and clear in the parent NSEC RR. + A security-aware resolver MUST use the parent NSEC RR when attempting + to prove that a DS RRset does not exist. + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3 Authenticating an RRset Using an RRSIG RR + + A validator can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The validator first checks the RRSIG + + + +Arends, et al. Expires November 15, 2004 [Page 27] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + 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. + +5.3.1 Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + o The RRSIG RR and the RRset MUST have the same owner name and the + same class; + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset; + o The RRSIG RR's Type Covered field MUST equal the RRset's type; + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field; + o The validator's notion of the current time MUST be less than or + equal to the time listed in the RRSIG RR's Expiration field; + o The validator's notion of the current time MUST be greater than or + equal to the time listed in the RRSIG RR's Inception field; + o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some DNSKEY RR in + the zone's apex DNSKEY RRset; + o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY + RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) + set to one. + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the 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. + + 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 + authentic; or + o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + and the DNSKEY RR either matches an authenticated DS RR from the + parent zone or matches a trust anchor. + +5.3.2 Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + + + +Arends, et al. Expires November 15, 2004 [Page 28] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + Section 5.3.1, the validator needs to reconstruct the original signed + data. The original signed data includes RRSIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The validator should use the following to + reconstruct the original signed data: + + signed_data = RRSIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signature field excluded and the Signer's Name + in canonical form. + + RR(i) = name | type | class | OrigTTL | RDATA length | RDATA + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the RRSIG Original TTL field + + All names in the RDATA field are in canonical form + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + + + +Arends, et al. Expires November 15, 2004 [Page 29] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + RRset. + + The canonical forms for names and RRsets are defined in + [I-D.ietf-dnsext-dnssec-records]. + + NSEC RRsets at a delegation boundary require special processing. + There are two distinct NSEC RRsets associated with a signed delegated + name. One NSEC RRset resides in the parent zone, and specifies which + RRset are present at the parent zone. The second NSEC RRset resides + at the child zone, and identifies which RRsets are present at the + apex in the child zone. The parent NSEC RRset and child NSEC RRset + can always be distinguished since only the child NSEC RRs will + specify an SOA RRset exists at the name. When reconstructing the + original NSEC RRset for the delegation from the parent zone, the NSEC + RRs MUST NOT be combined with NSEC RRs from the child zone, and when + reconstructing the original NSEC RRset for the apex of the child + zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent + zone. + + Note also that each of the two NSEC RRsets at a delegation point has + a corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + +5.3.3 Checking the Signature + + Once the resolver has validated the RRSIG RR as described in Section + 5.3.1 and reconstructed the original signed data as described in + Section 5.3.2, the validator can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). + [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types + and provides pointers to the documents that define each algorithm's + use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the 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 + of keys to try. + + + +Arends, et al. Expires November 15, 2004 [Page 30] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also needs to test these RRSIG + RRs, and determines how to resolve conflicts if these RRSIG RRs lead + to differing results. + + If the resolver accepts the RRset as authentic, the 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 + current time. + +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. + + 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 + + A resolver can use authenticated NSEC RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NSEC RRs for signed zones in + their responses to security-aware resolvers. + + Security-aware resolvers MUST first authenticate NSEC RRsets + according to the standard RRset authentication rules described in + Section 5.3, then apply the NSEC RRsets as follows: + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + + + +Arends, et al. Expires November 15, 2004 [Page 31] + +Internet-Draft DNSSEC Protocol Modifications May 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. + + To prove non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify non-existence of the requested RRset. As with all DNS + operations, however, the resolver MUST bound the work it puts into + answering any particular query. + + Since a validated NSEC RR proves the existence of both itself and its + 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 + + 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 + 4.7 on caching responses that do not validate. + +5.6 Authentication Example + + Appendix C shows an example the authentication process. + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 32] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +6. IANA Considerations + + [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA + considerations introduced by DNSSEC. The additional IANA + considerations discussed in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655] and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 33] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general + security considerations related to DNSSEC; see + [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the + DNSSEC resource record types. + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection which DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Section 3.2.2 and Section 4.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 + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will need to pay close attention to the + behavior of the applications which use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidentally denying service to the clients it + is intended to support. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 34] + +Internet-Draft DNSSEC Protocol Modifications May 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 November 15, 2004 [Page 35] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +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. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + +9.2 Informative References + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "KEY RR Secure Entry Point Flag", + draft-ietf-dnsext-nsec-rdata-05 (work in progress), March + + + +Arends, et al. Expires November 15, 2004 [Page 36] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + 2004. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + +Arends, et al. Expires November 15, 2004 [Page 37] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + 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 November 15, 2004 [Page 38] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB + 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE + VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO + 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM + W6OISukd1EQt7a0kygkg+PEDxdI= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + 3600 DNSKEY 256 3 5 ( + AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV + rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e + k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo + vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI + + + +Arends, et al. Expires November 15, 2004 [Page 39] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== + ) + 3600 DNSKEY 257 3 5 ( + AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl + LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ + syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP + RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT + Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 9465 example. + ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ + xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ + XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 + hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY + NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z + DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri + bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp + eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk + 7z5OXogYVaFzHKillDt3HRxHIZM= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba + U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 + 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I + BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g + sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + + + +Arends, et al. Expires November 15, 2004 [Page 40] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l + e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh + ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 + AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw + FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG + CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p + P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN + 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL + AhS+JOVfDI/79QtyTI0SaDWcg8U= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + + + +Arends, et al. Expires November 15, 2004 [Page 41] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE + VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb + 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH + l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw + Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + + + +Arends, et al. Expires November 15, 2004 [Page 42] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK + vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E + mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI + NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e + IjgiM8PXkBQtxPq37wDKALkyn7Q= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia + t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj + q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq + GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb + +gLcMZBnHJ326nb/TOOmrqNmQQE= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 + t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq + BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 + 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ + RgNvuwbioFSEuv2pNlkq0goYxNY= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + + + +Arends, et al. Expires November 15, 2004 [Page 43] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY + 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k + mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi + asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W + GghLahumFIpg4MO3LS/prgzVVWo= ) + + The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA + Flags indicate that each of these DNSKEY RRs is a zone key. One of + these DNSKEY RRs also has the SEP flag set and has been used to sign + the apex DNSKEY RRset; this is the key which should be hashed to + generate a DS record to be inserted into the parent zone. The other + DNSKEY is used to sign all the other RRsets in the zone. + + The zone includes a wildcard entry "*.w.example". Note that the name + "*.w.example" is used in constructing NSEC chains, and that the RRSIG + covering the "*.w.example" MX RRset has a label count of 2. + + The zone also includes two delegations. The delegation to + "b.example" includes an NS RRset, glue address records, and an NSEC + RR; note that only the NSEC RRset is signed. The delegation to + "a.example" provides a DS RR; note that only the NSEC and DS RRsets + are signed. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 44] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1 Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + + + +Arends, et al. Expires November 15, 2004 [Page 45] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + + +B.2 Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + + + +Arends, et al. Expires November 15, 2004 [Page 46] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + +B.3 No Data Error + + A "NODATA" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 47] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + + ;; Additional + ;; (empty) + + +B.4 Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 48] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + + ;; Additional + 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 + + 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 November 15, 2004 [Page 49] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + + +B.6 Wildcard Expansion + + A successful query which was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + + ;; Authority + + + +Arends, et al. Expires November 15, 2004 [Page 50] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + + +B.7 Wildcard No Data Error + + A "NODATA" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + + + +Arends, et al. Expires November 15, 2004 [Page 51] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + + ;; Additional + ;; (empty) + + +B.8 DS Child Zone No Data Error + + A "NODATA" response for a QTYPE=DS query which was mistakenly sent to + a name server for the child zone. + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 52] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 53] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1 Authenticating An Answer + + The query in section Appendix B.1 returned an MX RRset for + "x.w.example.com". The corresponding RRSIG indicates the MX RRset + was signed by an "example" DNSKEY with algorithm 5 and key tag 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, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates the answer was not + the result of wildcard expansion. The "x.w.example.com" MX RRset is + placed in canonical form and, assuming the current time falls between + the signature inception and expiration dates, the signature is + authenticated. + +C.1.1 Authenticating the example DNSKEY RR + + This example shows the logical authentication process that starts + from the a 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 + 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 + 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. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + + + +Arends, et al. Expires November 15, 2004 [Page 54] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + matching "example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the "example" + DNSKEY RRset are considered authenticated. + + Finally the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY + is used to authenticated 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. + +C.2 Name Error + + The query in section Appendix B.2 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3 No Data Error + + The query in section Appendix B.3 returned an NSEC RR that proves the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4 Referral to Signed Zone + + The query in section Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "a.example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the + "a.example" DNSKEY RRset are considered authenticated. + +C.5 Referral to Unsigned Zone + + The query in section Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + "example" to "b.example" and the NSEC RR is authenticated in a manner + + + +Arends, et al. Expires November 15, 2004 [Page 55] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + identical to that of the MX RRset discussed above. + +C.6 Wildcard Expansion + + The query in section Appendix B.6 returned an answer that was + produced as a result of wildcard expansion. The RRset expanded as the + similar to The corresponding RRSIG indicates the MX RRset was signed + by an "example" DNSKEY with algorithm 5 and key tag 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. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7 Wildcard No Data Error + + The query in section Appendix B.7 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8 DS Child Zone No Data Error + + The query in section Appendix B.8 returned NSEC RRs that shows the + requested was answered by a child server ("example" server). The + NSEC RR indicates the presence of an SOA RR, showing the answer is + from the child . Queries for the "example" DS RRset should be sent + to the parent servers ("root" servers). + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 56] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires November 15, 2004 [Page 57] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 58] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt similarity index 73% rename from doc/draft/draft-ietf-dnsext-dnssec-records-07.txt rename to doc/draft/draft-ietf-dnsext-dnssec-records-08.txt index cfd3567f0a..3ca99bfb72 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt @@ -1,2073 +1,1961 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 16, 2004 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - February 16, 2004 - - - Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-07 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents that describes the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of resource records and protocol modifications that - provide source authentication for the DNS. This document defines the - public key (DNSKEY), delegation signer (DS), resource record digital - - - -Arends, et al. Expires August 16, 2004 [Page 1] - -Internet-Draft DNSSEC Resource Records February 2004 - - - signature (RRSIG), and authenticated denial of existence (NSEC) - resource records. The purpose and format of each resource record is - described in detail, and an example of each resource record is given. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 6 - 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . . . . 7 - 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7 - 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8 - 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9 - 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . . 9 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 12 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 - 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13 - 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13 - 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15 - 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 - 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . . . . 16 - 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 17 - 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 17 - 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 19 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 19 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 20 - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 20 - - - -Arends, et al. Expires August 16, 2004 [Page 2] - -Internet-Draft DNSSEC Resource Records February 2004 - - - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20 - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 20 - 5.2 Processing of DS RRs When Validating Responses . . . . . . . 20 - 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 21 - 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 21 - 6. Canonical Form and Order of Resource Records . . . . . . . . 22 - 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 22 - 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 22 - 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 23 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . 26 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 - Normative References . . . . . . . . . . . . . . . . . . . . 28 - Informative References . . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 32 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 32 - A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 32 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34 - B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35 - Intellectual Property and Copyright Statements . . . . . . . 36 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 3] - -Internet-Draft DNSSEC Resource Records February 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the - purpose of each resource record (RR), the RR's RDATA format, and its - presentation format (ASCII representation). - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs - that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 - [RFC2308]. - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication and data integrity to the Domain Name - System (DNS). An introduction to DNSSEC and definitions of common - terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description - of DNS protocol modifications can be found in - [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC - resource records. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Open Technical Issues - - The cryptographic algorithm types (Appendix A) requires input from - the working group. The DSA algorithm was moved to OPTIONAL. This - had strong consensus in workshops and various discussions and a - separate Internet-Draft solely to move DSA from MANDATORY to OPTIONAL - seemed excessive. This draft solicits input on that proposed change. - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - - -Arends, et al. Expires August 16, 2004 [Page 4] - -Internet-Draft DNSSEC Resource Records February 2004 - - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 5] - -Internet-Draft DNSSEC Resource Records February 2004 - - -2. The DNSKEY Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in DNSKEY - resource records and are used in the DNSSEC authentication process - described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its - authoritative RRsets using a private key and stores the corresponding - public key in a DNSKEY RR. A resolver can then use the public key to - authenticate signatures covering the RRsets in the zone. - - The DNSKEY RR is not intended as a record for storing arbitrary - public keys, and MUST NOT be used to store certificates or public - keys that do not directly relate to the DNS infrastructure. - - The Type value for the DNSKEY RR type is 48. - - The DNSKEY RR is class independent. - - The DNSKEY RR has no special TTL requirements. - -2.1 DNSKEY RDATA Wire Format - - The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 - octet Protocol Field, a 1 octet Algorithm Field, and the Public Key - Field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Public Key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Flags Field - - Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, - then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner - name MUST be the name of a zone. If bit 7 has value 0, then the - DNSKEY record holds some other type of DNS public key, such as a - public key used by TKEY and MUST NOT be used to verify RRSIGs that - cover RRsets. - - Bit 15 of the Flags field is the Secure Entry Point flag, described - in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1, - - - -Arends, et al. Expires August 16, 2004 [Page 6] - -Internet-Draft DNSSEC Resource Records February 2004 - - - then the DNSKEY record holds a key intended for use as a secure entry - point. This flag is only intended to be to a hint to zone signing or - debugging software as to the intended use of this DNSKEY record; - security-aware resolvers MUST NOT alter their behavior during the - signature validation process in any way based on the setting of this - bit. - - Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon - creation of the DNSKEY RR, and MUST be ignored upon reception. - -2.1.2 The Protocol Field - - The Protocol Field MUST have value 3 and MUST be treated as invalid - during signature verification if found to be some value other than 3. - -2.1.3 The Algorithm Field - - The Algorithm field identifies the public key's cryptographic - algorithm and determines the format of the Public Key field. A list - of DNSSEC algorithm types can be found in Appendix A.1 - -2.1.4 The Public Key Field - - The Public Key Field holds the public key material. The format - depends on the algorithm of the key being stored and are described in - separate documents. - -2.1.5 Notes on DNSKEY RDATA Design - - Although the Protocol Field always has value 3, it is retained for - backward compatibility with early versions of the KEY record. - -2.2 The DNSKEY RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Flag field MUST be represented as an unsigned decimal integer - with a value of 0, 256, or 257. - - The Protocol Field MUST be represented as an unsigned decimal integer - with a value of 3. - - The Algorithm field MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Public Key field MUST be represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - - - -Arends, et al. Expires August 16, 2004 [Page 7] - -Internet-Draft DNSSEC Resource Records February 2004 - - - definition of Base64 encoding, see [RFC1521] Section 5.2. - -2.3 DNSKEY RR Example - - The following DNSKEY RR stores a DNS zone key for example.com. - - example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 - Cbl+BBZH4b/0PY1kxkmvHjcZc8no - kfzj31GajIQKY+5CptLr3buXA10h - WqTkF7H6RfoRqXQeogmMHfpftf6z - Mv1LyBUgia7za6ZEzOJBOztyvhjL - 742iU/TpPSEDhm2SNKLijfUppn1U - aNvv4w== ) - - The first four text fields specify the owner name, TTL, Class, and RR - type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in - the Flags field has value 1. Value 3 is the fixed Protocol value. - Value 5 indicates the public key algorithm. Appendix A.1 identifies - algorithm type 5 as RSA/SHA1 and indicates that the format of the - RSA/SHA1 public key field is defined in [RFC3110]. The remaining - text is a Base64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 8] - -Internet-Draft DNSSEC Resource Records February 2004 - - -3. The RRSIG Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). Digital signatures are stored in - RRSIG resource records and are used in the DNSSEC authentication - process described in [I-D.ietf-dnsext-dnssec-protocol]. A - security-aware resolver can use these RRSIG RRs to authenticate - RRsets from the zone. The RRSIG RR MUST only be used to carry - verification material (digital signatures) used to secure DNS - operations. - - An RRSIG record contains the signature for an RRset with a particular - name, class, and type. The RRSIG RR specifies a validity interval - for the signature and uses the Algorithm, the Signer's Name, and the - Key Tag to identify the DNSKEY RR containing the public key that a - resolver can use to verify the signature. - - Because every authoritative RRset in a zone must be protected by a - digital signature, RRSIG RRs must be present for names containing a - CNAME RR. This is a change to the traditional DNS specification - [RFC1034] that stated that if a CNAME is present for a name, it is - the only type allowed at that name. A RRSIG and NSEC (see Section 4) - MUST exist for the same name as a CNAME resource record in a secure - zone. - - The Type value for the RRSIG RR type is 46. - - The RRSIG RR is class independent. - - An RRSIG RR MUST have the same class as the RRset it covers. - - The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset - it covers. This is an exception to the [RFC2181] rules for TTL - values of individual RRs within a RRset: individual RRSIG with the - same owner name will have different TTL values if the RRsets that - they cover have different TTL values. - -3.1 RRSIG RDATA Wire Format - - The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a - 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original - TTL field, a 4 octet Signature Expiration field, a 4 octet Signature - Inception field, a 2 octet Key tag, the Signer's Name field, and the - Signature field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Arends, et al. Expires August 16, 2004 [Page 9] - -Internet-Draft DNSSEC Resource Records February 2004 - - - | Type Covered | Algorithm | Labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 The Type Covered Field - - The Type Covered field identifies the type of the RRset which is - covered by this RRSIG record. - -3.1.2 The Algorithm Number Field - - The Algorithm Number field identifies the cryptographic algorithm - used to create the signature. A list of DNSSEC algorithm types can - be found in Appendix A.1 - -3.1.3 The Labels Field - - The Labels field specifies the number of labels in the original RRSIG - RR owner name. The significance of this field is that from it a - verifier can determine if the answer was synthesized from a wildcard. - If so, it can be used to determine what owner name was used in - generating the signature. - - To validate a signature, the validator needs the original owner name - that was used to create the signature. If the original owner name - contains a wildcard label ("*"), the owner name may have been - expanded by the server during the response process, in which case the - validator will need to reconstruct the original owner name in order - to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] - describes how to use the Labels field to reconstruct the original - owner name. - - The value of the Labels field MUST NOT count either the null (root) - label that terminates the owner name or the wildcard label (if - - - -Arends, et al. Expires August 16, 2004 [Page 10] - -Internet-Draft DNSSEC Resource Records February 2004 - - - present). The value of the Labels field MUST be less than or equal - to the number of labels in the RRSIG owner name. For example, - "www.example.com." has a Labels field value of 3, and - "*.example.com." has a Labels field value of 2. Root (".") has a - Labels field value of 0. - - Although the wildcard label is not included in the count stored in - the Labels field of the RRSIG RR, the wildcard label is part of the - RRset's owner name when generating or verifying the signature. - -3.1.4 Original TTL Field - - The Original TTL field specifies the TTL of the covered RRset as it - appears in the authoritative zone. - - The Original TTL field is necessary because a caching resolver - decrements the TTL value of a cached RRset. In order to validate a - signature, a resolver requires the original TTL. - [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original - TTL field value to reconstruct the original TTL. - -3.1.5 Signature Expiration and Inception Fields - - The Signature Expiration and Inception fields specify a validity - period for the signature. The RRSIG record MUST NOT be used for - authentication prior to the inception date and MUST NOT be used for - authentication after the expiration date. - - Signature Expiration and Inception field values are in POSIX.1 time - format: a 32-bit unsigned number of seconds elapsed since 1 January - 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The - longest interval which can be expressed by this format without - wrapping is approximately 136 years. An RRSIG RR can have an - Expiration field value which is numerically smaller than the - Inception field value if the expiration field value is near the - 32-bit wrap-around point or if the signature is long lived. Because - of this, all comparisons involving these fields MUST use "Serial - number arithmetic" as defined in [RFC1982]. As a direct consequence, - the values contained in these fields cannot refer to dates more than - 68 years in either the past or the future. - -3.1.6 The Key Tag Field - - The Key Tag field contains the key tag value of the DNSKEY RR that - validates this signature. Appendix B explains how to calculate Key - Tag values. - - - - - -Arends, et al. Expires August 16, 2004 [Page 11] - -Internet-Draft DNSSEC Resource Records February 2004 - - -3.1.7 The Signer's Name Field - - The Signer's Name field value identifies the owner name of the DNSKEY - RR which a security-aware resolver should use to validate this - signature. The Signer's Name field MUST contain the name of the zone - of the covered RRset. A sender MUST NOT use DNS name compression on - the Signer's Name field when transmitting a RRSIG RR. A receiver - which receives an RRSIG RR containing a compressed Signer's Name - field SHOULD decompress the field value. - -3.1.8 The Signature Field - - The Signature field contains the cryptographic signature which covers - the RRSIG RDATA (excluding the Signature field) and the RRset - specified by the RRSIG owner name, RRSIG class, and RRSIG Type - Covered field. The format of this field depends on the algorithm in - use and these formats are described in separate companion documents. - -3.1.8.1 Signature Calculation - - A signature covers the RRSIG RDATA (excluding the Signature Field) - and covers the data RRset specified by the RRSIG owner name, RRSIG - class, and RRSIG Type Covered fields. The RRset is in canonical form - (see Section 6) and the set RR(1),...RR(n) is signed as follows: - - signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes concatenation; - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signer's Name field in canonical form and - the Signature field excluded; - - RR(i) = owner | class | type | TTL | RDATA length | RDATA; - - "owner" is the fully qualified owner name of the RRset in - canonical form (for RRs with wildcard owner names, the - wildcard label is included in the owner name); - - Each RR MUST have the same owner name as the RRSIG RR; - - Each RR MUST have the same class as the RRSIG RR; - - Each RR in the RRset MUST have the RR type listed in the - RRSIG RR's Type Covered field; - - Each RR in the RRset MUST have the TTL listed in the - RRSIG Original TTL Field; - - - -Arends, et al. Expires August 16, 2004 [Page 12] - -Internet-Draft DNSSEC Resource Records February 2004 - - - Any DNS names in the RDATA field of each RR MUST be in - canonical form; and - - The RRset MUST be sorted in canonical order. - - -3.2 The RRSIG RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Type Covered field value MUST be represented either as an - unsigned decimal integer or as the mnemonic for the covered RR type. - - The Algorithm field value MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Labels field value MUST be represented as an unsigned decimal - integer. - - The Original TTL field value MUST be represented as an unsigned - decimal integer. - - The Signature Expiration Time and Inception Time field values MUST be - represented in the form YYYYMMDDHHmmSS in UTC, where: - - YYYY is the year (0000-9999, but see Section 3.1.5); - - MM is the month number (01-12); - - DD is the day of the month (01-31); - - HH is the hour in 24 hours notation (00-23); - - mm is the minute (00-59); - - SS is the second (00-59). - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Signer's Name field value MUST be represented as a domain name. - - The Signature field is represented as a Base64 encoding of the - signature. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding see [RFC1521] Section 5.2. - -3.3 RRSIG RR Example - - - - -Arends, et al. Expires August 16, 2004 [Page 13] - -Internet-Draft DNSSEC Resource Records February 2004 - - - The following an RRSIG RR stores the signature for the A RRset of - host.example.com: - - host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( - 20030220173103 2642 example.com. - oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr - PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o - B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t - GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG - J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) - - The first four fields specify the owner name, TTL, Class, and RR type - (RRSIG). The "A" represents the Type Covered field. The value 5 - identifies the algorithm used (RSA/SHA1) to create the signature. - The value 3 is the number of Labels in the original owner name. The - value 86400 in the RRSIG RDATA is the Original TTL for the covered A - RRset. 20030322173103 and 20030220173103 are the expiration and - inception dates, respectively. 2642 is the Key Tag, and example.com. - is the Signer's Name. The remaining text is a Base64 encoding of the - signature. - - Note that combination of RRSIG RR owner name, class, and Type Covered - indicate that this RRSIG covers the "host.example.com" A RRset. The - Label value of 3 indicates that no wildcard expansion was used. The - Algorithm, Signer's Name, and Key Tag indicate this signature can be - authenticated using an example.com zone DNSKEY RR whose algorithm is - 5 and key tag is 2642. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 14] - -Internet-Draft DNSSEC Resource Records February 2004 - - -4. The NSEC Resource Record - - The NSEC resource record lists two separate things: the owner name of - the next authoritative RRset in the canonical ordering of the zone, - and the set of RR types present at the NSEC RR's owner name. The - complete set of NSEC RRs in a zone both indicate which authoritative - RRsets exist in a zone and also form a chain of authoritative owner - names in the zone. This information is used to provide authenticated - denial of existence for DNS data, as described in - [I-D.ietf-dnsext-dnssec-protocol]. - - Because every authoritative name in a zone must be part of the NSEC - chain, NSEC RRs must be present for names containing a CNAME RR. - This is a change to the traditional DNS specification [RFC1034] that - stated that if a CNAME is present for a name, it is the only type - allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist - for the same name as a CNAME resource record in a secure zone. - - The type value for the NSEC RR is 47. - - The NSEC RR is class independent. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirt of negative caching [RFC2308]. - -4.1 NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4.1.1 The Next Domain Name Field - - The Next Domain Name field contains the owner name of the next - authoritative owner name in the canonical ordering of the zone; see - Section 6.1 for an explanation of canonical ordering. The value of - the Next Domain Name field in the last NSEC record in the zone is the - name of the zone apex (the owner name of the zone's SOA RR). - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. A receiver which receives an - - - -Arends, et al. Expires August 16, 2004 [Page 15] - -Internet-Draft DNSSEC Resource Records February 2004 - - - NSEC RR containing a compressed Next Domain Name field SHOULD - decompress the field value. - - Owner names of RRsets not authoritative for the given zone (such as - glue records) MUST NOT be listed in the Next Domain Name unless at - least one authoritative RRset exists at the same owner name. - -4.1.2 The Type Bit Maps Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC RR's owner name. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that has - at least one active RR type is encoded using a single octet window - number (from 0 to 255), a single octet bitmap length (from 1 to 32) - indicating the number of octets used for the window block's bitmap, - and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC - RR's owner name. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC RR's owner name. - - Since bit 0 in window block 0 refers to the non-existent RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing pseudo-types MUST be set to 0, since they do not - appear in zone data. If encountered, they MUST be ignored upon - reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - - - -Arends, et al. Expires August 16, 2004 [Page 16] - -Internet-Draft DNSSEC Resource Records February 2004 - - - interpreted as zero octets. - - A zone MUST NOT generate an NSEC RR for any domain name that only - holds glue records. - -4.1.3 Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards - on authenticated denial of existence. - -4.2 The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE representation - as described in [RFC3597] (section 5) MUST be used. - -4.3 NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. ( - A MX RRSIG NSEC TYPE1234 ) - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - - - -Arends, et al. Expires August 16, 2004 [Page 17] - -Internet-Draft DNSSEC Resource Records February 2004 - - - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the resolver can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - [I-D.ietf-dnsext-dnssec-protocol]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 18] - -Internet-Draft DNSSEC Resource Records February 2004 - - -5. The DS Resource Record - - The DS Resource Record refers to a DNSKEY RR and is used in the DNS - DNSKEY authentication process. A DS RR refers to a DNSKEY RR by - storing the key tag, algorithm number, and a digest of the DNSKEY RR. - Note that while the digest should be sufficient to identify the - public key, storing the key tag and key algorithm helps make the - identification process more efficient. By authenticating the DS - record, a resolver can authenticate the DNSKEY RR to which the DS - record points. The key authentication process is described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The DS RR and its corresponding DNSKEY RR have the same owner name, - but they are stored in different locations. The DS RR appears only - on the upper (parental) side of a delegation, and is authoritative - data in the parent zone. For example, the DS RR for "example.com" is - stored in the "com" zone (the parent zone) rather than in the - "example.com" zone (the child zone). The corresponding DNSKEY RR is - stored in the "example.com" zone (the child zone). This simplifies - DNS zone management and zone signing, but introduces special response - processing requirements for the DS RR; these are described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - The DS RR has no special TTL requirements. - -5.1 DS RDATA Wire Format - - The RDATA for a DS RR consists of a 2 octet Key Tag field, a one - octet Algorithm field, a one octet Digest Type field, and a Digest - field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | Digest Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 19] - -Internet-Draft DNSSEC Resource Records February 2004 - - -5.1.1 The Key Tag Field - - The Key Tag field lists the key tag of the DNSKEY RR referred to by - the DS record. - - The Key Tag used by the DS RR is identical to the Key Tag used by - RRSIG RRs. Appendix B describes how to compute a Key Tag. - -5.1.2 The Algorithm Field - - The Algorithm field lists the algorithm number of the DNSKEY RR - referred to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm - number types. - -5.1.3 The Digest Type Field - - The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY - RR. The Digest Type field identifies the algorithm used to construct - the digest. Appendix A.2 lists the possible digest algorithm types. - -5.1.4 The Digest Field - - The DS record refers to a DNSKEY RR by including a digest of that - DNSKEY RR. - - The digest is calculated by concatenating the canonical form of the - fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, - and then applying the digest algorithm. - - digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); - - "|" denotes concatenation - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. - - - The size of the digest may vary depending on the digest algorithm and - DNSKEY RR size. As of the time of writing, the only defined digest - algorithm is SHA-1, which produces a 20 octet digest. - -5.2 Processing of DS RRs When Validating Responses - - The DS RR links the authentication chain across zone boundaries, so - the DS RR requires extra care in processing. The DNSKEY RR referred - to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST - - - -Arends, et al. Expires August 16, 2004 [Page 20] - -Internet-Draft DNSSEC Resource Records February 2004 - - - have Flags bit 7 set to value 1. If the key tag does not indicate a - DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT be - used in the validation process. - -5.3 The DS RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic specified in Appendix A.1. - - The Digest Type field MUST be represented as an unsigned decimal - integer. - - The Digest MUST be represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is allowed within the hexadecimal - text. - -5.4 DS RR Example - - The following example shows a DNSKEY RR and its corresponding DS RR. - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A - 98631FAD1A292118 ) - - - The first four text fields specify the name, TTL, Class, and RR type - (DS). Value 60485 is the key tag for the corresponding - "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm - used by this "dskey.example.com." DNSKEY RR. The value 1 is the - algorithm used to construct the digest, and the rest of the RDATA - text is the digest in hexadecimal. - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 21] - -Internet-Draft DNSSEC Resource Records February 2004 - - -6. Canonical Form and Order of Resource Records - - This section defines a canonical form for resource records, a - canonical ordering of DNS names, and a canonical ordering of resource - records within an RRset. A canonical name order is required to - construct the NSEC name chain. A canonical RR form and ordering - within an RRset are required to construct and verify RRSIG RRs. - -6.1 Canonical DNS Name Order - - For purposes of DNS security, owner names are ordered by treating - individual labels as unsigned left-justified octet strings. The - absence of a octet sorts before a zero value octet, and upper case - US-ASCII letters are treated as if they were lower case US-ASCII - letters. - - To compute the canonical ordering of a set of DNS names, start by - sorting the names according to their most significant (rightmost) - labels. For names in which the most significant label is identical, - continue sorting according to their next most significant label, and - so forth. - - For example, the following names are sorted in canonical DNS name - order. The most significant label is "example". At this level, - "example" sorts first, followed by names ending in "a.example", then - names ending "z.example". The names within each level are sorted in - the same way. - - example - a.example - yljkjljk.a.example - Z.a.example - zABC.a.EXAMPLE - z.example - \001.z.example - *.z.example - \200.z.example - - -6.2 Canonical RR Form - - For purposes of DNS security, the canonical form of an RR is the wire - format of the RR where: - - 1. Every domain name in the RR is fully expanded (no DNS name - compression) and fully qualified; - - 2. All uppercase US-ASCII letters in the owner name of the RR are - - - -Arends, et al. Expires August 16, 2004 [Page 22] - -Internet-Draft DNSSEC Resource Records February 2004 - - - replaced by the corresponding lowercase US-ASCII letters; - - 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, - HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, - SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in - the DNS names contained within the RDATA are replaced by the - corresponding lowercase US-ASCII letters; - - 4. If the owner name of the RR is a wildcard name, the owner name is - in its original unexpanded form, including the "*" label (no - wildcard substitution); and - - 5. The RR's TTL is set to its original value as it appears in the - originating authoritative zone or the Original TTL field of the - covering RRSIG RR. - - -6.3 Canonical RR Ordering Within An RRset - - For purposes of DNS security, RRs with the same owner name, class, - and type are sorted by treating the RDATA portion of the canonical - form of each RR as a left-justified unsigned octet sequence where the - absence of an octet sorts before a zero octet. - - [RFC2181] specifies that an RRset is not allowed to contain duplicate - records (multiple RRs with the same owner name, class, type, and - RDATA). Therefore, if an implementation detects duplicate RRs during - RRset canonicalization, the implementation MUST treat this as a - protocol error. If the implementation chooses to handle this - protocol error in the spirit of the robustness principle (being - liberal in what it accepts), the implementation MUST remove all but - one of the duplicate RR(s) for purposes of calculating the canonical - form of the RRset. - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 23] - -Internet-Draft DNSSEC Resource Records February 2004 - - -7. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by previous specifications. However, since the evolution of - DNSSEC has been long and somewhat convoluted, this section attempts - to describe the current state of the IANA registries and other - protocol parameters which are (or once were) related to DNSSEC. - - Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA - considerations. - - DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to - the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS - Resource Record Type 43 to DS. - [I-D.ietf-dnsext-dnssec-2535typecode-change] assigned types 46, - 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. - [I-D.ietf-dnsext-dnssec-2535typecode-change] also marked type 30 - (NXT) as Obsolete, and restricted use of types 24 (SIG) and 25 - (KEY) to the "SIG(0)" transaction security protocol described in - [RFC2931] and the transaction KEY Resource Record described in - [RFC2930]. - - DNS Security Algorithm Numbers: [RFC2535] created an IANA registry - for DNSSEC Resource Record Algorithm field numbers, and assigned - values 1-4 and 252-255. [RFC3110] assigned value 5. - [I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry - to include flags for each entry regarding its use with the DNS - security extensions. Each algorithm entry could refer to an - algorithm that can be used for zone signing, transaction security - (see [RFC2931]) or both. Values 6-251 are available for assignment - by IETF standards action. See Appendix A for a full listing of the - DNS Security Algorithm Numbers entries at the time of writing and - their status of use in DNSSEC. - - [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and - assigned value 0 to reserved and value 1 to SHA-1. - - KEY Protocol Values: [RFC2535] created an IANA Registry for KEY - Protocol Values, but [RFC3445] re-assigned all assigned values - other than 3 to reserved and closed this IANA registry. The - registry remains closed, and all KEY and DNSKEY records are - required to have Protocol Octet value of 3. - - Flag bits in the KEY and DNSKEY RRs: - [I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA - registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, - this registry only contains an assignment for bit 7 (the ZONE bit) - - - -Arends, et al. Expires August 16, 2004 [Page 24] - -Internet-Draft DNSSEC Resource Records February 2004 - - - and a reservation for bit 15 for the Secure Entry Point flag (SEP - bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14 - are available for assignment by IETF Standards Action. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 25] - -Internet-Draft DNSSEC Resource Records February 2004 - - -8. Security Considerations - - This document describes the format of four DNS resource records used - by the DNS security extensions, and presents an algorithm for - calculating a key tag for a public key. Other than the items - described below, the resource records themselves introduce no - security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] - and [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations related to the use of these records. - - The DS record points to a DNSKEY RR using a cryptographic digest, the - key algorithm type and a key tag. The DS record is intended to - identify an existing DNSKEY RR, but it is theoretically possible for - an attacker to generate a DNSKEY that matches all the DS fields. The - probability of constructing such a matching DNSKEY depends on the - type of digest algorithm in use. The only currently defined digest - algorithm is SHA-1, and the working group believes that constructing - a public key which would match the algorithm, key tag, and SHA-1 - digest given in a DS record would be a sufficiently difficult problem - that such an attack is not a serious threat at this time. - - The key tag is used to help select DNSKEY resource records - efficiently, but it does not uniquely identify a single DNSKEY - resource record. It is possible for two distinct DNSKEY RRs to have - the same owner name, the same algorithm type, and the same key tag. - An implementation which used only the key tag to select a DNSKEY RR - might select the wrong public key in some circumstances. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 26] - -Internet-Draft DNSSEC Resource Records February 2004 - - -9. Acknowledgments - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 27] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet - Mail Extensions) Part One: Mechanisms for Specifying and - Describing the Format of Internet Message Bodies", RFC - 1521, September 1993. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [I-D.ietf-dnsext-dnssec-intro] - - - -Arends, et al. Expires August 16, 2004 [Page 28] - -Internet-Draft DNSSEC Resource Records February 2004 - - - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-09 (work in progress), - February 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in - progress), February 2004. - - [I-D.ietf-dnsext-keyrr-key-signing-flag] - Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", - draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in - progress), December 2003. - - [I-D.ietf-dnsext-dnssec-2535typecode-change] - Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 - (work in progress), December 2003. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 29] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Informative References - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - - - - -Arends, et al. Expires August 16, 2004 [Page 30] - -Internet-Draft DNSSEC Resource Records February 2004 - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 31] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security extensions are designed to be independent of the - underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS - resource records all use a DNSSEC Algorithm Number to identify the - cryptographic algorithm in use by the resource record. The DS - resource record also specifies a Digest Algorithm Number to identify - the digest algorithm used to construct the DS record. The currently - defined Algorithm and Digest Types are listed below. Additional - Algorithm or Digest Types could be added as advances in cryptography - warrant. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1 DNSSEC Algorithm Types - - The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify - the security algorithm being used. These values are stored in the - "Algorithm number" field in the resource record RDATA. - - Some algorithms are usable only for zone signing (DNSSEC), some only - for transaction security mechanisms (SIG(0) and TSIG), and some for - both. Those usable for zone signing may appear in DNSKEY, RRSIG, and - DS RRs. Those usable for transaction security would be present in - SIG(0) and KEY RRs as described in [RFC2931] - - Zone - Value Algorithm [Mnemonic] Signing References Status - ----- -------------------- --------- ---------- --------- - 0 reserved - 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman [DH] n RFC 2539 - - 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL - 4 Elliptic Curve [ECC] TBA - - 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY - 252 Indirect [INDIRECT] n - - 253 Private [PRIVATEDNS] y see below OPTIONAL - 254 Private [PRIVATEOID] y see below OPTIONAL - 255 reserved - - 6 - 251 Available for assignment by IETF Standards Action. - -A.1.1 Private Algorithm Types - - Algorithm number 253 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with a wire encoded - - - -Arends, et al. Expires August 16, 2004 [Page 32] - -Internet-Draft DNSSEC Resource Records February 2004 - - - domain name, which MUST NOT be compressed. The domain name indicates - the private algorithm to use and the remainder of the public key area - is determined by that algorithm. Entities should only use domain - names they control to designate their private algorithms. - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with an unsigned - length byte followed by a BER encoded Object Identifier (ISO OID) of - that length. The OID indicates the private algorithm in use and the - remainder of the area is whatever is required by that algorithm. - Entities should only use OIDs they control to designate their private - algorithms. - -A.2 DNSSEC Digest Types - - A "Digest Type" field in the DS resource record types identifies the - cryptographic digest algorithm used by the resource record. The - following table lists the currently defined digest algorithm types. - - VALUE Algorithm STATUS - 0 Reserved - - 1 SHA-1 MANDATORY - 2-255 Unassigned - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 33] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Appendix B. Key Tag Calculation - - The Key Tag field in the RRSIG and DS resource record types provides - a mechanism for selecting a public key efficiently. In most cases, a - combination of owner name, algorithm, and key tag can efficiently - identify a DNSKEY record. Both the RRSIG and DS resource records - have corresponding DNSKEY records. The Key Tag field in the RRSIG - and DS records can be used to help select the corresponding DNSKEY RR - efficiently when more than one candidate DNSKEY RR is available. - - However, it is essential to note that the key tag is not a unique - identifier. It is theoretically possible for two distinct DNSKEY RRs - to have the same owner name, the same algorithm, and the same key - tag. The key tag is used to limit the possible candidate keys, but it - does not uniquely identify a DNSKEY record. Implementations MUST NOT - assume that the key tag uniquely identifies a DNSKEY RR. - - The key tag is the same for all DNSKEY algorithm types except - algorithm 1 (please see Appendix B.1 for the definition of the key - tag for algorithm 1). The key tag algorithm is the sum of the wire - format of the DNSKEY RDATA broken into 2 octet groups. First the - RDATA (in wire format) is treated as a series of 2 octet groups, - these groups are then added together ignoring any carry bits. A - reference implementation of the key tag algorithm is as an ANSI C - function is given below with the RDATA portion of the DNSKEY RR is - used as input. It is not necessary to use the following reference - code verbatim, but the numerical value of the Key Tag MUST be - identical to what the reference implementation would generate for the - same input. - - Please note that the algorithm for calculating the Key Tag is almost - but not completely identical to the familiar ones complement checksum - used in many other Internet protocols. Key Tags MUST be calculated - using the algorithm described here rather than the ones complement - checksum. - - The following ANSI C reference implementation calculates the value of - a Key Tag. This reference implementation applies to all algorithm - types except algorithm 1 (see Appendix B.1). The input is the wire - format of the RDATA portion of the DNSKEY RR. The code is written - for clarity, not efficiency. - - /* - * Assumes that int is at least 16 bits. - * First octet of the key tag is the most significant 8 bits of the - * return value; - * Second octet of the key tag is the least significant 8 bits of the - * return value. - - - -Arends, et al. Expires August 16, 2004 [Page 34] - -Internet-Draft DNSSEC Resource Records February 2004 - - - */ - - unsigned int - keytag ( - unsigned char key[], /* the RDATA part of the DNSKEY RR */ - unsigned int keysize /* the RDLENGTH */ - ) - { - unsigned long ac; /* assumed to be 32 bits or larger */ - int i; /* loop index */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i & 1) ? key[i] : key[i] << 8; - ac += (ac >> 16) & 0xFFFF; - return ac & 0xFFFF; - } - - -B.1 Key Tag for Algorithm 1 (RSA/MD5) - - The key tag for algorithm 1 (RSA/MD5) is defined differently than the - key tag for all other algorithms, for historical reasons. For a - DNSKEY RR with algorithm 1, the key tag is defined to be the most - significant 16 bits of the least significant 24 bits in the public - key modulus (in other words, the 4th to last and 3rd to last octets - of the public key modulus). - - Please note that Algorithm 1 is NOT RECOMMENDED. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 35] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires August 16, 2004 [Page 36] - -Internet-Draft DNSSEC Resource Records February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 37] - - + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: November 15, 2004 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + May 17, 2004 + + + Resource Records for the DNS Security Extensions + draft-ietf-dnsext-dnssec-records-08 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents that describes the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + public key (DNSKEY), delegation signer (DS), resource record digital + + + +Arends, et al. Expires November 15, 2004 [Page 1] + +Internet-Draft DNSSEC Resource Records May 2004 + + + signature (RRSIG), and authenticated denial of existence (NSEC) + resource records. The purpose and format of each resource record is + described in detail, and an example of each resource record is given. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Technical Changes or Corrections . . . . . . . . . . . 4 + 1.3.2 Typos and Minor Corrections . . . . . . . . . . . . . 5 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 6 + 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 6 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 6 + 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 7 + 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 7 + 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 7 + 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 7 + 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 7 + 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 8 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 9 + 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 9 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 10 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 10 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 10 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 11 + 3.1.5 Signature Expiration and Inception Fields . . . . . . 11 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 11 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 12 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 12 + 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 13 + 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 15 + 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 15 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 15 + 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 16 + 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 17 + 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 17 + 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 17 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 19 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 19 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 20 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 20 + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 20 + + + +Arends, et al. Expires November 15, 2004 [Page 2] + +Internet-Draft DNSSEC Resource Records May 2004 + + + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 20 + 5.2 Processing of DS RRs When Validating Responses . . . . . . 20 + 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 21 + 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 21 + 6. Canonical Form and Order of Resource Records . . . . . . . . . 22 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 22 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 22 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 23 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 + 10.2 Informative References . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 30 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 30 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 30 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 31 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 32 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 33 + Intellectual Property and Copyright Statements . . . . . . . . 34 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 3] + +Internet-Draft DNSSEC Resource Records May 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the + purpose of each resource record (RR), the RR's RDATA format, and its + presentation format (ASCII representation). + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035] and subsequent RFCs that update + them: [RFC2136], [RFC2181] and [RFC2308]. + + This document is part of a family of documents that define the DNS + security extensions. The DNS security extensions (DNSSEC) are a + collection of resource records and DNS protocol modifications that + add source authentication and data integrity to the Domain Name + System (DNS). An introduction to DNSSEC and definitions of common + terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description + of DNS protocol modifications can be found in + [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC + resource records. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3 Editors' Notes + +1.3.1 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + + + + + + +Arends, et al. Expires November 15, 2004 [Page 4] + +Internet-Draft DNSSEC Resource Records May 2004 + + +1.3.2 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 5] + +Internet-Draft DNSSEC Resource Records May 2004 + + +2. The DNSKEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in DNSKEY + resource records and are used in the DNSSEC authentication process + described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its + authoritative RRsets using a private key and stores the corresponding + public key in a DNSKEY RR. A resolver can then use the public key to + authenticate signatures covering the RRsets in the zone. + + The DNSKEY RR is not intended as a record for storing arbitrary + public keys and MUST NOT be used to store certificates or public keys + that do not directly relate to the DNS infrastructure. + + The Type value for the DNSKEY RR type is 48. + + The DNSKEY RR is class independent. + + The DNSKEY RR has no special TTL requirements. + +2.1 DNSKEY RDATA Wire Format + + The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 + octet Protocol Field, a 1 octet Algorithm Field, and the Public Key + Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner + name MUST be the name of a zone. If bit 7 has value 0, then the + DNSKEY record holds some other type of DNS public key, such as a + public key used by TKEY and MUST NOT be used to verify RRSIGs that + cover RRsets. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a + + + +Arends, et al. Expires November 15, 2004 [Page 6] + +Internet-Draft DNSSEC Resource Records May 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 is an invalid DNSKEY. + + Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon + creation of the DNSKEY RR, and MUST be ignored upon reception. + +2.1.2 The Protocol Field + + The Protocol Field MUST have value 3 and the DNSKEY RR MUST be + treated as invalid during signature verification if found to be some + value other than 3. + +2.1.3 The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4 The Public Key Field + + The Public Key Field holds the public key material. The format + depends on the algorithm of the key being stored and are described in + separate documents. + +2.1.5 Notes on DNSKEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with early versions of the KEY record. + +2.2 The DNSKEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field MUST be represented as an unsigned decimal integer + with a value of 0, 256, or 257. + + The Protocol Field MUST be represented as an unsigned decimal integer + with a value of 3. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + + + +Arends, et al. Expires November 15, 2004 [Page 7] + +Internet-Draft DNSSEC Resource Records May 2004 + + + 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 [RFC1521] Section 5.2. + +2.3 DNSKEY RR Example + + The following DNSKEY RR stores a DNS zone key for example.com. + + example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 + Cbl+BBZH4b/0PY1kxkmvHjcZc8no + kfzj31GajIQKY+5CptLr3buXA10h + WqTkF7H6RfoRqXQeogmMHfpftf6z + Mv1LyBUgia7za6ZEzOJBOztyvhjL + 742iU/TpPSEDhm2SNKLijfUppn1U + aNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in + the Flags field has value 1. Value 3 is the fixed Protocol value. + Value 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [RFC3110]. The remaining + text is a Base64 encoding of the public key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 8] + +Internet-Draft DNSSEC Resource Records May 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. + + An RRSIG record contains the signature for an RRset with a particular + name, class, and type. The RRSIG RR specifies a validity interval + for the signature and uses the Algorithm, the Signer's Name, and the + Key Tag to identify the DNSKEY RR containing the public key that a + validator can use to verify the signature. + + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034] that stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a signed + zone. + + The Type value for the RRSIG RR type is 46. + + The RRSIG RR is class independent. + + An RRSIG RR MUST have the same class as the RRset it covers. + + The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset + it covers. This is an exception to the [RFC2181] rules for TTL + values of individual RRs within a RRset: individual RRSIG with the + same owner name will have different TTL values if the RRsets they + cover have different TTL values. + +3.1 RRSIG RDATA Wire Format + + The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a + 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original + TTL field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 9] + +Internet-Draft DNSSEC Resource Records May 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 The Type Covered Field + + The Type Covered field identifies the type of the RRset that is + covered by this RRSIG record. + +3.1.2 The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3 The Labels Field + + The Labels field specifies the number of labels in the original RRSIG + RR owner name. The significance of this field is that 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. + + 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 November 15, 2004 [Page 10] + +Internet-Draft DNSSEC Resource Records May 2004 + + + The value of the Labels field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Labels field MUST be less than or equal + to the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Labels field value of 3, and + "*.example.com." has a Labels field value of 2. Root (".") has a + Labels field value of 0. + + Although the wildcard label is not included in the count stored in + the Labels field of the RRSIG RR, the wildcard label is part of the + RRset's owner name when generating or verifying the signature. + +3.1.4 Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a 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. + +3.1.5 Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The RRSIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + Signature Expiration and Inception field values are in POSIX.1 time + format: a 32-bit unsigned number of seconds elapsed since 1 January + 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The + longest interval which can be expressed by this format without + wrapping is approximately 136 years. An RRSIG RR can have an + Expiration field value which is numerically smaller than the + Inception field value if the expiration field value is near the + 32-bit wrap-around point or if the signature is long lived. Because + of this, all comparisons involving these fields MUST use "Serial + number arithmetic" as defined in [RFC1982]. As a direct consequence, + the values contained in these fields cannot refer to dates more than + 68 years in either the past or the future. + +3.1.6 The Key Tag Field + + The Key Tag field contains the key tag value of the DNSKEY RR that + validates this signature. Appendix B explains how to calculate Key + Tag values. + + + +Arends, et al. Expires November 15, 2004 [Page 11] + +Internet-Draft DNSSEC Resource Records May 2004 + + +3.1.7 The Signer's Name Field + + The Signer's Name field value identifies the owner name of the DNSKEY + RR which a validator should use to validate this signature. The + Signer's Name field MUST contain the name of the zone of the covered + RRset. A sender MUST NOT use DNS name compression on the Signer's + Name field when transmitting a RRSIG RR. + +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. + +3.1.8.1 Signature Calculation + + A signature covers the RRSIG RDATA (excluding the Signature Field) + and covers the data RRset specified by the RRSIG owner name, RRSIG + class, and RRSIG Type Covered fields. The RRset is in canonical form + (see Section 6) and the set RR(1),...RR(n) is signed as follows: + + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | type | class | TTL | RDATA length | RDATA + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the RRSIG RR; + + Each RR MUST have the same class as the RRSIG RR; + + Each RR in the RRset MUST have the RR type listed in the + RRSIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the + RRSIG Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + + + +Arends, et al. Expires November 15, 2004 [Page 12] + +Internet-Draft DNSSEC Resource Records May 2004 + + + canonical form; and + + The RRset MUST be sorted in canonical order. + + See Section 6.1 and Section 6.2 for details on canonical name order + and canonical RR form. + +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 mnemonic is not known, the TYPE representation as described in + [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 + A.1. + + The Labels field value MUST be represented as an unsigned decimal + integer. + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Expiration Time and Inception Time field values MUST be + represented either as seconds since 1 January 1970 00:00:00 UTC or in + the form YYYYMMDDHHmmSS in UTC, where: + YYYY is the year (0000-9999, but see Section 3.1.5); + MM is the month number (01-12); + DD is the day of the month (01-31); + HH is the hour in 24 hours notation (00-23); + mm is the minute (00-59); and + SS is the second (00-59). + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Signer's Name field value MUST be represented as a domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. See + Section 2.2. + +3.3 RRSIG RR Example + + The following RRSIG RR stores the signature for the A RRset of + host.example.com: + + + + +Arends, et al. Expires November 15, 2004 [Page 13] + +Internet-Draft DNSSEC Resource Records May 2004 + + + host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + The first four fields specify the owner name, TTL, Class, and RR type + (RRSIG). The "A" represents the Type Covered field. The value 5 + identifies the algorithm used (RSA/SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the RRSIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of RRSIG RR owner name, class, and Type Covered + indicate that this RRSIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate this signature can be + authenticated using an example.com zone DNSKEY RR whose algorithm is + 5 and key tag is 2642. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 14] + +Internet-Draft DNSSEC Resource Records May 2004 + + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the owner name of + the next authoritative RRset in the canonical ordering of the zone, + and the set of RR types present at the NSEC RR's owner name. The + complete set of NSEC RRs in a zone both indicate which authoritative + RRsets exist in a zone and also form a chain of authoritative owner + names in the zone. This information is used to provide authenticated + denial of existence for DNS data, as described in + [I-D.ietf-dnsext-dnssec-protocol]. + + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034] that + stated that if a CNAME is present for a name, it is the only type + allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist + for the same name as a CNAME resource record in a 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 + zone. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +4.1 NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The Next Domain Name field contains the owner name of the next + authoritative owner name in the canonical ordering of the zone; see + Section 6.1 for an explanation of canonical ordering. The value of + the Next Domain Name field in the last NSEC record in the zone is the + + + +Arends, et al. Expires November 15, 2004 [Page 15] + +Internet-Draft DNSSEC Resource Records May 2004 + + + name of the zone apex (the owner name of the zone's SOA RR). + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets not authoritative for the given zone (such as + glue records) MUST NOT be listed in the Next Domain Name unless at + least one authoritative RRset exists at the same owner name. + +4.1.2 The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC RR's owner name. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that has + at least one active RR type is encoded using a single octet window + number (from 0 to 255), a single octet bitmap length (from 1 to 32) + indicating the number of octets used for the window block's bitmap, + and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC RR's owner name. + + Bits representing pseudo-types MUST be set to 0, since they do not + appear in zone data. If encountered, they MUST be ignored upon + reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + interpreted as zero octets. + + + + +Arends, et al. Expires November 15, 2004 [Page 16] + +Internet-Draft DNSSEC Resource Records May 2004 + + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set to + 1; bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be set to 0. + + 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 + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for purposes of generating NSEC RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards + on authenticated denial of existence. + +4.2 The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + as described in [RFC3597] (section 5) MUST be used. + +4.3 NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, + and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and + TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 17] + +Internet-Draft DNSSEC Resource Records May 2004 + + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 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 November 15, 2004 [Page 18] + +Internet-Draft DNSSEC Resource Records May 2004 + + +5. The DS Resource Record + + The DS Resource Record refers to a DNSKEY RR and is used in the DNS + DNSKEY authentication process. A DS RR refers to a DNSKEY RR by + storing the key tag, algorithm number, and a digest of the DNSKEY RR. + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The DS RR and its corresponding DNSKEY RR have the same owner name, + but they are stored in different locations. The DS RR appears only + on the upper (parental) side of a delegation, and is authoritative + data in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + "example.com" zone (the child zone). The corresponding DNSKEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing, but introduces special response + processing requirements for the DS RR; these are described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + The DS RR has no special TTL requirements. + +5.1 DS RDATA Wire Format + + The RDATA for a DS RR consists of a 2 octet Key Tag field, a one + octet Algorithm field, a one octet Digest Type field, and a Digest + field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 19] + +Internet-Draft DNSSEC Resource Records May 2004 + + +5.1.1 The Key Tag Field + + The Key Tag field lists the key tag of the DNSKEY RR referred to by + the DS record. + + The Key Tag used by the DS RR is identical to the Key Tag used by + RRSIG RRs. Appendix B describes how to compute a Key Tag. + +5.1.2 The Algorithm Field + + The Algorithm field lists the algorithm number of the DNSKEY RR + referred to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm + number types. + +5.1.3 The Digest Type Field + + The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY + RR. The Digest Type field identifies the algorithm used to construct + the digest. Appendix A.2 lists the possible digest algorithm types. + +5.1.4 The Digest Field + + The DS record refers to a DNSKEY RR by including a digest of that + DNSKEY RR. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, + and then applying the digest algorithm. + + digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); + + "|" denotes concatenation + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. + + + The size of the digest may vary depending on the digest algorithm and + DNSKEY RR size. As of the time of writing, the only defined digest + algorithm is SHA-1, which produces a 20 octet digest. + +5.2 Processing of DS RRs When Validating Responses + + The DS RR links the authentication chain across zone boundaries, so + the DS RR requires extra care in processing. The DNSKEY RR referred + to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST + + + +Arends, et al. Expires November 15, 2004 [Page 20] + +Internet-Draft DNSSEC Resource Records May 2004 + + + have Flags bit 7 set to value 1. 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. + +5.3 The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field MUST be represented as an unsigned decimal + integer. + + The Digest MUST be represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.4 DS RR Example + + The following example shows a DNSKEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm + used by this "dskey.example.com." DNSKEY RR. The value 1 is the + algorithm used to construct the digest, and the rest of the RDATA + text is the digest in hexadecimal. + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 21] + +Internet-Draft DNSSEC Resource Records May 2004 + + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NSEC name chain. A canonical RR form and ordering + within an RRset are required to construct and verify RRSIG RRs. + +6.1 Canonical DNS Name Order + + For purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and upper case + US-ASCII letters are treated as if they were lower case US-ASCII + letters. + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + names ending "z.example". The names within each level are sorted in + the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + + +6.2 Canonical RR Form + + For purposes of DNS security, the canonical form of an RR is the wire + format of the RR where: + 1. Every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + 2. All uppercase US-ASCII letters in the owner name of the RR are + replaced by the corresponding lowercase US-ASCII letters; + + + + +Arends, et al. Expires November 15, 2004 [Page 22] + +Internet-Draft DNSSEC Resource Records May 2004 + + + 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in + the DNS names contained within the RDATA are replaced by the + corresponding lowercase US-ASCII letters; + 4. If the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + 5. The RR's TTL is set to its original value as it appears in the + originating authoritative zone or the Original TTL field of the + covering RRSIG RR. + +6.3 Canonical RR Ordering Within An RRset + + For purposes of DNS security, RRs with the same owner name, class, + and type are sorted by treating the RDATA portion of the canonical + form of each RR as a left-justified unsigned octet sequence where the + absence of an octet sorts before a zero octet. + + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs 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 November 15, 2004 [Page 23] + +Internet-Draft DNSSEC Resource Records May 2004 + + +7. IANA Considerations + + This document introduces no new IANA considerations, because all of + the protocol parameters used in this document have already been + assigned by previous specifications. However, since the evolution of + DNSSEC has been long and somewhat convoluted, this section attempts + to describe the current state of the IANA registries and other + protocol parameters which are (or once were) related to DNSSEC. + + Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA + considerations. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS + Resource Record Type 43 to DS. [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]. + + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers, and assigned + values 1-4 and 252-255. [RFC3110] assigned value 5. [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 + available for assignment by IETF standards action. See Appendix A + for a full listing of the DNS Security Algorithm Numbers entries + at the time of writing and their status of use in DNSSEC. + + [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and + assigned value 0 to reserved and value 1 to SHA-1. + + KEY Protocol Values: [RFC2535] created an IANA Registry for KEY + Protocol Values, but [RFC3445] re-assigned all values other than 3 + to reserved and closed this IANA registry. The registry remains + closed, and all KEY and DNSKEY records are required to have + Protocol Octet value of 3. + + Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains an assignment for bit 7 (the ZONE bit) + and a reservation for bit 15 for the Secure Entry Point flag (SEP + bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by + IETF Standards Action. + + + + +Arends, et al. Expires November 15, 2004 [Page 24] + +Internet-Draft DNSSEC Resource Records May 2004 + + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions, and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] + and [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations related to the use of these records. + + The DS record points to a DNSKEY RR using a cryptographic digest, the + key algorithm type and a key tag. The DS record is intended to + identify an existing DNSKEY RR, but it is theoretically possible for + an attacker to generate a DNSKEY that matches all the DS fields. The + probability of constructing such a matching DNSKEY depends on the + type of digest algorithm in use. The only currently defined digest + algorithm is SHA-1, and the working group believes that constructing + a public key which would match the algorithm, key tag, and SHA-1 + digest given in a DS record would be a sufficiently difficult problem + that such an attack is not a serious threat at this time. + + The key tag is used to help select DNSKEY resource records + efficiently, but it does not uniquely identify a single DNSKEY + resource record. It is possible for two distinct DNSKEY RRs to have + the same owner name, the same algorithm type, and the same key tag. + An implementation which uses only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 25] + +Internet-Draft DNSSEC Resource Records May 2004 + + +9. Acknowledgments + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 26] + +Internet-Draft DNSSEC Resource Records May 2004 + + +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. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet + Mail Extensions) Part One: Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1521, September 1993. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + + +Arends, et al. Expires November 15, 2004 [Page 27] + +Internet-Draft DNSSEC Resource Records May 2004 + + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + +10.2 Informative References + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "KEY RR Secure Entry Point Flag", + draft-ietf-dnsext-nsec-rdata-05 (work in progress), March + 2004. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 28] + +Internet-Draft DNSSEC Resource Records May 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 November 15, 2004 [Page 29] + +Internet-Draft DNSSEC Resource Records May 2004 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS + resource records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1 DNSSEC Algorithm Types + + The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify + the security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. + + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs as described in [RFC2931] + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman [DH] n RFC 2539 - + 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. + +A.1.1 Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with a wire encoded + + + +Arends, et al. Expires November 15, 2004 [Page 30] + +Internet-Draft DNSSEC Resource Records May 2004 + + + domain name, which MUST NOT be compressed. The domain name indicates + the private algorithm to use and the remainder of the public key area + is determined by that algorithm. Entities should only use domain + names they control to designate their private algorithms. + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with an unsigned + length byte followed by a BER encoded Object Identifier (ISO OID) of + that length. The OID indicates the private algorithm in use and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2 DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 31] + +Internet-Draft DNSSEC Resource Records May 2004 + + +Appendix B. Key Tag Calculation + + The Key Tag field in the RRSIG and DS resource record types provides + a mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a DNSKEY record. Both the RRSIG and DS resource records + have corresponding DNSKEY records. The Key Tag field in the RRSIG + and DS records can be used to help select the corresponding DNSKEY RR + efficiently when more than one candidate DNSKEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct DNSKEY RRs + to have the same owner name, the same algorithm, and the same key + tag. The key tag is used to limit the possible candidate keys, but it + does not uniquely identify a DNSKEY record. Implementations MUST NOT + assume that the key tag uniquely identifies a DNSKEY RR. + + The key tag is the same for all DNSKEY algorithm types except + algorithm 1 (please see Appendix B.1 for the definition of the key + tag for algorithm 1). The key tag algorithm is the sum of the wire + format of the DNSKEY RDATA broken into 2 octet groups. First the + RDATA (in wire format) is treated as a series of 2 octet groups, + these groups are then added together ignoring any carry bits. + + A reference implementation of the key tag algorithm is as an ANSI C + function is given below with the RDATA portion of the DNSKEY RR is + used as input. It is not necessary to use the following reference + code verbatim, but the numerical value of the Key Tag MUST be + identical to what the reference implementation would generate for the + same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described here rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the DNSKEY RR. The code is written + for clarity, not efficiency. + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 32] + +Internet-Draft DNSSEC Resource Records May 2004 + + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the DNSKEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + +B.1 Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently than the + key tag for all other algorithms, for historical reasons. For a + DNSKEY RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 33] + +Internet-Draft DNSSEC Resource Records May 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires November 15, 2004 [Page 34] + +Internet-Draft DNSSEC Resource Records May 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 35] + +