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