diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt | 1457 |
1 files changed, 1457 insertions, 0 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt new file mode 100644 index 000000000000..0783e7b26e14 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt @@ -0,0 +1,1457 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: January 13, 2005 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + July 15, 2004 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-11 + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 13, 2005. + +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 + + + +Arends, et al. Expires January 13, 2005 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + document introduces these extensions, and describes their + capabilities and limitations. This document also discusses the + services that the DNS security extensions do and do not provide. + Last, this document describes the interrelationships between the + group of documents that collectively describe DNSSEC. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 + 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 + 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 + 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 + 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 + 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 + 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 + 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 + 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 + 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 + 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . . . . . 26 + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents + ([I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the + security extensions defined in RFC 2535 [RFC2535] and its + predecessors. These security extensions consist of a set of new + resource record types and modifications to the existing DNS protocol + [RFC1035]. The new records and protocol modifications are not fully + described in this document, but are described in a family of + documents outlined in Section 10. Section 3 and Section 4 describe + the capabilities and limitations of the security extensions in + greater detail. Section 5 discusses the scope of the document set. + Section 6, Section 7, Section 8, and Section 9 discuss the effect + that these security extensions will have on resolvers, stub + resolvers, zones and name servers. + + This document and its two companions update and obsolete RFCs 2535 + [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 + [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress + [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but + does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 + [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts + of 3226 [RFC3226] (dealing with DNSSEC). + + The DNS security extensions provide origin authentication and + integrity protection for DNS data, as well as a means of public key + distribution. These extensions do not provide confidentiality. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +2. Definitions of Important DNSSEC Terms + + This section defines a number of terms used in this document set. + Since this is intended to be useful as a reference while reading the + rest of the document set, first-time readers may wish to skim this + section quickly, read the rest of this document, then come back to + this section. + + Authentication Chain: An alternating sequence of DNSKEY RRsets and DS + RRsets forms a chain of signed data, with each link in the chain + vouching for the next. A DNSKEY RR is used to verify the + signature covering a DS RR and allows the DS RR to be + authenticated. The DS RR contains a hash of another DNSKEY RR and + this new DNSKEY RR is authenticated by matching the hash in the DS + RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset + and, in turn, some DNSKEY RR in this set may be used to + authenticate another DS RR and so forth until the chain finally + ends with a DNSKEY RR whose corresponding private key signs the + desired DNS data. For example, the root DNSKEY RRset can be used + to authenticate the DS RRset for "example." The "example." DS + RRset contains a hash that matches some "example." DNSKEY, and + this DNSKEY's corresponding private key signs the "example." + DNSKEY RRset. Private key counterparts of the "example." DNSKEY + RRset sign data records such as "www.example." as well as DS RRs + for delegations such as "subzone.example." + + Authentication Key: A public key that a security-aware resolver has + verified and can therefore use to authenticate data. A + security-aware resolver can obtain authentication keys in three + ways. First, the resolver is generally configured to know about + at least one public key; this configured data is usually either + the public key itself or a hash of the public key as found in the + DS RR (see "trust anchor"). Second, the resolver may use an + authenticated public key to verify a DS RR and the DNSKEY RR to + which the DS RR refers. Third, the resolver may be able to + determine that a new public key has been signed by the private key + corresponding to another public key which the resolver has + verified. Note that the resolver must always be guided by local + policy when deciding whether to authenticate a new public key, + even if the local policy is simply to authenticate any new public + key for which the resolver is able verify the signature. + + Delegation Point: Term used to describe the name at the parental side + of a zone cut. That is, the delegation point for "foo.example" + would be the foo.example node in the "example" zone (as opposed to + the zone apex of the "foo.example" zone). + + + + + +Arends, et al. Expires January 13, 2005 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + Island of Security: Term used to describe a signed, delegated zone + that does not have an authentication chain from its delegating + parent. That is, there is no DS RR containing a hash of a DNSKEY + RR for the island in its delegating parent zone (see + [I-D.ietf-dnsext-dnssec-records]). An island of security is + served by security-aware name servers and may provide + authentication chains to any delegated child zones. Responses + from an island of security or its descendents can only be + authenticated if its authentication keys can be authenticated by + some trusted means out of band from the DNS protocol. + + Key Signing Key (KSK): An authentication key that corresponds to a + private key used to sign one or more other authentication keys for + a given zone. Typically, the private key corresponding to a key + signing key will sign a zone signing key, which in turn has a + corresponding private key which will sign other zone data. Local + policy may require the zone signing key to be changed frequently, + while the key signing key may have a longer validity period in + order to provide a more stable secure entry point into the zone. + Designating an authentication key as a key signing key is purely + an operational issue: DNSSEC validation does not distinguish + between key signing keys and other DNSSEC authentication keys, and + it is possible to use a single key as both a key signing key and a + zone signing key. Key signing keys are discussed in more detail + in [RFC3757]. Also see: zone signing key. + + Non-Validating Security-Aware Stub Resolver: A security-aware stub + resolver which trusts one or more security-aware recursive name + servers to perform most of the tasks discussed in this document + set on its behalf. In particular, a non-validating security-aware + stub resolver is an entity which sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server which will + provide these services on behalf of the security-aware stub + resolver. See also: security-aware stub resolver, validating + security-aware stub resolver. + + Non-Validating Stub Resolver: A less tedious term for a + non-validating security-aware stub resolver. + + Security-Aware Name Server: An entity acting in the role of a name + server (defined in section 2.4 of [RFC1034]) that understands the + DNS security extensions defined in this document set. In + particular, a security-aware name server is an entity which + receives DNS queries, sends DNS responses, supports the EDNS0 + [RFC2671] message size extension and the DO bit [RFC3225], and + supports the RR types and message header bits defined in this + document set. + + + +Arends, et al. Expires January 13, 2005 [Page 5] + + + Security-Aware Recursive Name Server: An entity which acts in both + the security-aware name server and security-aware resolver roles. + A more cumbersome equivalent phrase would be "a security-aware + name server which offers recursive service". + + Security-Aware Resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [RFC1034]) which understands the DNS + security extensions defined in this document set. In particular, + a security-aware resolver is an entity which sends DNS queries, + receives DNS responses, supports the EDNS0 [RFC2671] message size + extension and the DO bit [RFC3225], and is capable of using the RR + types and message header bits defined in this document set to + provide DNSSEC services. + + Security-Aware Stub Resolver: An entity acting in the role of a stub + resolver (defined in section 5.3.1 of [RFC1034]) which has enough + of an understanding the DNS security extensions defined in this + document set to provide additional services not available from a + security-oblivious stub resolver. Security-aware stub resolvers + may be either "validating" or "non-validating" depending on + whether the stub resolver attempts to verify DNSSEC signatures on + its own or trusts a friendly security-aware name server to do so. + See also: validating stub resolver, non-validating stub resolver. + + Security-Oblivious <anything>: An <anything> that is not + "security-aware". + + Signed Zone: A zone whose RRsets are signed and which contains + properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS + records. + + Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A + validating security-aware resolver uses this public key or hash as + a starting point for building the authentication chain to a signed + DNS response. In general, a validating resolver will need to + obtain the initial values of its trust anchors via some secure or + trusted means outside the DNS protocol. Presence of a trust + anchor also implies that the resolver should expect the zone to + which the trust anchor points to be signed. + + Unsigned Zone: A zone that is not signed. + + Validating Security-Aware Stub Resolver: A security-aware resolver + that sends queries in recursive mode but which performs signature + validation on its own rather than just blindly trusting an + upstream security-aware recursive name server. See also: + security-aware stub resolver, non-validating security-aware stub + resolver. + + + + + +Arends, et al. Expires January 13, 2005 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + Validating Stub Resolver: A less tedious term for a validating + security-aware stub resolver. + + Zone Signing Key (ZSK): An authentication key that corresponds to a + private key used to sign a zone. Typically a zone signing key + will be part of the same DNSKEY RRset as the key signing key whose + corresponding private key signs this DNSKEY RRset, but the zone + signing key is used for a slightly different purpose, and may + differ from the key signing key in other ways, such as validity + lifetime. Designating an authentication key as a zone signing key + is purely an operational issue: DNSSEC validation does not + distinguish between zone signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. See also: key + signing key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements July 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. The keys associated with transaction security may be + stored in different RR types. See [RFC3755] for details.). + + A security-aware resolver can learn a zone's public key either by + having a trust anchor configured into the resolver or by normal DNS + resolution. To allow the latter, public keys are stored in a new + type of resource record, the DNSKEY RR. Note that the private keys + used to sign zone data must be kept secure, and should be stored + offline when practical to do so. To discover a public key reliably + via DNS resolution, the target key itself needs to be signed by + either a configured authentication key or another key that has been + 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, + + + +Arends, et al. Expires January 13, 2005 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + which in turn either has been configured into the resolver or must + have been learned and verified previously. Therefore, the resolver + must be configured with at least one trust anchor. If the configured + key is a zone signing key, then it will authenticate the associated + zone; if the configured key is a key signing key, it will + authenticate a zone signing key. If the resolver has been configured + with the hash of a key rather than the key itself, the resolver may + need to obtain the key via a DNS query. To help security-aware + resolvers establish this authentication chain, security-aware name + servers attempt to send the signature(s) needed to authenticate a + zone's public key(s) in the DNS reply message along with the public + key itself, provided there is space available in the message. + + The Delegation Signer (DS) RR type simplifies some of the + administrative tasks involved in signing delegations across + organizational boundaries. The DS RRset resides at a delegation + point in a parent zone and indicates the public key(s) corresponding + to the private key(s) used to self-sign the DNSKEY RRset at the + delegated child zone's apex. The administrator of the child zone, in + turn, uses the private key(s) corresponding to one or more of the + public keys in this DNSKEY RRset to sign the child zone's data. The + typical authentication chain is therefore + DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more + DS->DNSKEY subchains. DNSSEC permits more complex authentication + chains, such as additional layers of DNSKEY RRs signing other DNSKEY + RRs within a zone. + + A security-aware resolver normally constructs this authentication + chain from the root of the DNS hierarchy down to the leaf zones based + on configured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to use one + or more configured public keys (or hashes of public keys) other than + the root public key, or may not provide configured knowledge of the + root public key, or may prevent the resolver from using particular + public keys for arbitrary reasons even if those public keys are + properly signed with verifiable signatures. DNSSEC provides + mechanisms by which a security-aware resolver can determine whether + an RRset's signature is "valid" within the meaning of DNSSEC. In the + final analysis however, authenticating both DNS keys and data is a + matter of local policy, which may extend or even override the + protocol extensions defined in this document set. See Section 5 for + further discussion. + +3.2 Authenticating Name and Type Non-Existence + + The security mechanism described in Section 3.1 only provides a way + to sign existing RRsets in a zone. The problem of providing negative + responses with the same level of authentication and integrity + + + +Arends, et al. Expires January 13, 2005 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + requires the use of another new resource record type, the NSEC + record. The NSEC record allows a security-aware resolver to + authenticate a negative reply for either name or type non-existence + via the same mechanisms used to authenticate other DNS replies. Use + 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 January 13, 2005 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + on cryptographic operations. Please see Section 12 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above are not designed to + protect operations such as zone transfers and dynamic update + [RFC3007]. Message authentication schemes described in [RFC2845] and + [RFC2931] address security operations that pertain to these + transactions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +5. Scope of the DNSSEC Document Set and Last Hop Issues + + The specification in this document set defines the behavior for zone + signers and security-aware name servers and resolvers in such a way + that the validating entities can unambiguously determine the state of + the data. + + A validating resolver can determine these 4 states: + + Secure: The validating resolver has a trust anchor, a chain of trust + and is able to verify all the signatures in the response. + + Insecure: The validating resolver has a trust anchor, a chain of + trust, and, at some delegation point, signed proof of the + non-existence of a DS record. That indicates that subsequent + branches in the tree are provably insecure. A validating resolver + may have local policy to mark parts of the domain space as + insecure. + + Bogus: The validating resolver has a trust anchor and there is a + secure delegation which is indicating that subsidiary data will be + signed, but the response fails to validate due to one or more + reasons: missing signatures, expired signatures, signatures with + unsupported algorithms, data missing which the relevant NSEC RR + says should be present, and so forth. + + Indeterminate: There is no trust anchor which would indicate that a + specific portion of the tree is secure. This is the default + operation mode. + + This specification only defines how security aware name servers can + signal non-validating stub resolvers that data was found to be bogus + (using RCODE=2, "Server Failure" -- see + [I-D.ietf-dnsext-dnssec-protocol]). + + There is a mechanism for security aware name servers to signal + security-aware stub resolvers that data was found to be secure (using + the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). + + This specification does not define a format for communicating why + responses were found to be bogus or marked as insecure. The current + signaling mechanism does not distinguish between indeterminate and + insecure. + + A method for signaling advanced error codes and policy between a + security aware stub resolver and security aware recursive nameservers + is a topic for future work, as is the interface between a security + aware resolver and the applications that use it. Note, however, that + + + +Arends, et al. Expires January 13, 2005 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + the lack of the specification of such communication does not prohibit + deployment of signed zones or the deployment of security aware + recursive name servers that prohibit propagation of bogus data to the + applications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +6. Resolver Considerations + + A security-aware resolver needs to be able to perform cryptographic + functions necessary to verify digital signatures using at least the + mandatory-to-implement algorithm(s). Security-aware resolvers must + also be capable of forming an authentication chain from a newly + learned zone back to an authentication key, as described above. This + process might require additional queries to intermediate DNS zones to + obtain necessary DNSKEY, DS and RRSIG records. A security-aware + resolver should be configured with at least one trust anchor as the + starting point from which it will attempt to establish authentication + chains. + + If a security-aware resolver is separated from the relevant + authoritative name servers by a recursive name server or by any sort + of device which acts as a proxy for DNS, and if the recursive name + server or proxy is not security-aware, the security-aware resolver + may not be capable of operating in a secure mode. For example, if a + security-aware resolver's packets are routed through a network + address translation device that includes a DNS proxy which is not + security-aware, the security-aware resolver may find it difficult or + impossible to obtain or validate signed DNS data. + + If a security-aware resolver must rely on an unsigned zone or a name + server that is not security aware, the resolver may not be able to + validate DNS responses, and will need a local policy on whether to + accept unverified responses. + + A security-aware resolver should take a signature's validation period + into consideration when determining the TTL of data in its cache, to + avoid caching signed data beyond the validity period of the + signature, but should also allow for the possibility that the + security-aware resolver's own clock is wrong. Thus, a security-aware + resolver which is part of a security-aware recursive name server will + need to pay careful attention to the DNSSEC "checking disabled" (CD) + bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid + blocking valid signatures from getting through to other + security-aware resolvers which are clients of this recursive name + server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure + recursive server handles queries with the CD bit set. + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +7. Stub Resolver Considerations + + Although not strictly required to do so by the protocol, most DNS + queries originate from stub resolvers. Stub resolvers, by + definition, are minimal DNS resolvers which use recursive query mode + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + architecture has to take stub resolvers into account, but the + security features needed in a stub resolver differ in some respects + from those needed in a full security-aware resolver. + + Even a security-oblivious stub resolver may get some benefit from + DNSSEC if the recursive name servers it uses are security-aware, but + for the stub resolver to place any real reliance on DNSSEC services, + the stub resolver must trust both the recursive name servers in + question and the communication channels between itself and those name + servers. The first of these issues is a local policy issue: in + essence, a security-oblivious stub resolver has no real choice but to + place itself at the mercy of the recursive name servers that it uses, + since it does not perform DNSSEC validity checks on its own. The + second issue requires some kind of channel security mechanism; proper + use of DNS transaction authentication mechanisms such as SIG(0) or + TSIG would suffice, as would appropriate use of IPsec, and particular + implementations may have other choices available, such as operating + system specific interprocess communication mechanisms. + Confidentiality is not needed for this channel, but data integrity + and message authentication are. + + A security-aware stub resolver that does trust both its recursive + name servers and its communication channel to them may choose to + examine the setting of the AD bit in the message header of the + response messages it receives. The stub resolver can use this flag + bit as a hint to find out whether the recursive name server was able + to validate signatures for all of the data in the Answer and + Authority sections of the response. + + There is one more step that a security-aware stub resolver can take + if, for whatever reason, it is not able to establish a useful trust + relationship with the recursive name servers which it uses: it can + perform its own signature validation, by setting the Checking + Disabled (CD) bit in its query messages. A validating stub resolver + is thus able to treat the DNSSEC signatures as a trust relationship + between the zone administrator and the stub resolver itself. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +8. Zone Considerations + + There are several differences between signed and unsigned zones. A + signed zone will contain additional security-related records (RRSIG, + DNSKEY, DS and NSEC records). RRSIG and NSEC records may be + generated by a signing process prior to serving the zone. The RRSIG + records that accompany zone data have defined inception and + expiration times, which establish a validity period for the + signatures and the zone data the signatures cover. + +8.1 TTL values vs. RRSIG validity period + + It is important to note the distinction between a RRset's TTL value + and the signature validity period specified by the RRSIG RR covering + that RRset. DNSSEC does not change the definition or function of the + TTL value, which is intended to maintain database coherency in + caches. A caching resolver purges RRsets from its cache no later + than the end of the time period specified by the TTL fields of those + RRsets, regardless of whether or not the resolver is security-aware. + + The inception and expiration fields in the RRSIG RR + [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time + period during which the signature can be used to validate the covered + RRset. The signatures associated with signed zone data are only + valid for the time period specified by these fields in the RRSIG RRs + in question. TTL values cannot extend the validity period of signed + RRsets in a resolver's cache, but the resolver may use the time + remaining before expiration of the signature validity period of a + signed RRset as an upper bound for the TTL of the signed RRset and + its associated RRSIG RR in the resolver's cache. + +8.2 New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency which did not + exist in the original DNS protocol. A signed zone requires regular + maintenance to ensure that each RRset in the zone has a current valid + RRSIG RR. The signature validity period of an RRSIG RR is an + interval during which the signature for one particular signed RRset + can be considered valid, and the signatures of different RRsets in a + zone may expire at different times. Re-signing one or more RRsets in + a zone will change one or more RRSIG RRs, which in turn will require + incrementing the zone's SOA serial number to indicate that a zone + change has occurred and re-signing the SOA RRset itself. Thus, + re-signing any RRset in a zone may also trigger DNS NOTIFY messages + and zone transfers operations. + + + + + + +Arends, et al. Expires January 13, 2005 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +9. Name Server Considerations + + A security-aware name server should include the appropriate DNSSEC + records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from + resolvers which have signaled their willingness to receive such + records via use of the DO bit in the EDNS header, subject to message + size limitations. Since inclusion of these DNSSEC RRs could easily + cause UDP message truncation and fallback to TCP, a security-aware + name server must also support the EDNS "sender's UDP payload" + mechanism. + + If possible, the private half of each DNSSEC key pair should be kept + offline, but this will not be possible for a zone for which DNS + dynamic update has been enabled. In the dynamic update case, the + primary master server for the zone will have to re-sign the zone when + updated, so the private key corresponding to the zone signing key + will have to be kept online. This is an example of a situation where + the ability to separate the zone's DNSKEY RRset into zone signing + key(s) and key signing key(s) may be useful, since the key signing + key(s) in such a case can still be kept offline and may have a longer + useful lifetime than the zone signing key(s). + + DNSSEC, by itself, is not enough to protect the integrity of an + entire zone during zone transfer operations, since even a signed zone + contains some unsigned, nonauthoritative data if the zone has any + children. Therefore, zone maintenance operations will require some + additional mechanisms (most likely some form of channel security, + such as TSIG, SIG(0), or IPsec). + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +10. DNS Security Document Family + + The DNSSEC document set can be partitioned into several main groups, + under the larger umbrella of the DNS base protocol documents. + + The "DNSSEC protocol document set" refers to the three documents + which form the core of the DNS security extensions: + 1. DNS Security Introduction and Requirements (this document) + 2. Resource Records for DNS Security Extensions + [I-D.ietf-dnsext-dnssec-records] + 3. Protocol Modifications for the DNS Security Extensions + [I-D.ietf-dnsext-dnssec-protocol] + + Additionally, any document that would add to, or change the core DNS + Security extensions would fall into this category. This includes any + future work on the communication between security-aware stub + resolvers and upstream security-aware recursive name servers. + + The "Digital Signature Algorithm Specification" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + record format. Each document in this set deals with a specific + digital signature algorithm. + + The "Transaction Authentication Protocol" document set refers to the + group of documents that deal with DNS message authentication, + including secret key establishment and verification. While not + strictly part of the DNSSEC specification as defined in this set of + documents, this group is noted because of its relationship to DNSSEC. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. DNSSEC does not provide any direct security for + these new uses, but may be used to support them. Documents that fall + in this category include the use of DNS in the storage and + distribution of certificates [RFC2538]. + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +11. IANA Considerations + + This overview document introduces no new IANA considerations. Please + see [I-D.ietf-dnsext-dnssec-records] for a complete review of the + IANA considerations introduced by DNSSEC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +12. Security Considerations + + This document introduces the DNS security extensions and describes + the document set that contains the new security records and DNS + protocol modifications. The extensions provide data origin + authentication and data integrity using digital signatures over + resource record sets.This document discusses the capabilities and + limitations of these extensions. + + In order for a security-aware resolver to validate a DNS response, + all zones along the path from the trusted starting point to the zone + containing the response zones must be signed, and all name servers + and resolvers involved in the resolution process must be + security-aware, as defined in this document set. A security-aware + resolver cannot verify responses originating from an unsigned zone, + from a zone not served by a security-aware name server, or for any + DNS data which the resolver is only able to obtain through a + recursive name server which is not security-aware. If there is a + break in the authentication chain such that a security-aware resolver + cannot obtain and validate the authentication keys it needs, then the + security-aware resolver cannot validate the affected DNS data. + + This document briefly discusses other methods of adding security to a + DNS query, such as using a channel secured by IPsec or using a DNS + transaction authentication mechanism, but transaction security is not + part of DNSSEC per se. + + A non-validating security-aware stub resolver, by definition, does + not perform DNSSEC signature validation on its own, and thus is + vulnerable both to attacks on (and by) the security-aware recursive + name servers which perform these checks on its behalf and also to + attacks on its communication with those security-aware recursive name + servers. Non-validating security-aware stub resolvers should use + some form of channel security to defend against the latter threat. + The only known defense against the former threat would be for the + security-aware stub resolver to perform its own signature validation, + at which point, again by definition, it would no longer be a + non-validating security-aware stub resolver. + + DNSSEC does not protect against denial of service attacks. DNSSEC + makes DNS vulnerable to a new class of denial of service attacks + based on cryptographic operations against security-aware resolvers + and security-aware name servers, since an attacker can attempt to use + DNSSEC mechanisms to consume a victim's resources. This class of + attacks takes at least two forms. An attacker may be able to consume + resources in a security-aware resolver's signature validation code by + tampering with RRSIG RRs in response messages or by constructing + needlessly complex signature chains. An attacker may also be able to + + + +Arends, et al. Expires January 13, 2005 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements July 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 does not provide confidentiality, due to a deliberate design + choice. + + 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. + + 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 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 January 13, 2005 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +13. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group. While explicitly listing everyone + who has contributed during the decade during which DNSSEC has been + under development would be an impossible task, the editors would + particularly like to thank the following people for their + contributions to and comments on this document set: Jaap Akkerhuis, + Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, + David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald + Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, + Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip + Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, + Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon + Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, + Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, + Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ + Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, + Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob + Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and + Suzanne Woolf. + + No doubt the above list is incomplete. We apologize to anyone we + left out. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +14. References + +14.1 Normative References + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in + progress), May 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-08 (work in progress), + May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + +14.2 Informative References + + [I-D.ietf-dnsext-dns-threats] + Atkins, D. and R. Austein, "Threat Analysis Of The Domain + Name System", draft-ietf-dnsext-dns-threats-07 (work in + progress), April 2004. + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "DNSSEC NSEC RDATA Format", + draft-ietf-dnsext-nsec-rdata-06 (work in progress), May + 2004. + + + +Arends, et al. Expires January 13, 2005 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in + the Domain Name System (DNS)", RFC 2538, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 24] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + +Arends, et al. Expires January 13, 2005 [Page 25] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 13, 2005 [Page 26] + + |