📄 draft-ietf-dnsext-dnssec-intro-05.txt
字号:
DNS Extensions R. ArendsInternet-Draft Telematica InstituutExpires: August 15, 2003 R. Austein ISC M. Larson VeriSign D. Massey USC/ISI S. Rose NIST February 14, 2003 DNS Security Introduction and Requirements draft-ietf-dnsext-dnssec-intro-05Status 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 15, 2003.Copyright Notice Copyright (C) The Internet Society (2003). 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 theArends, et al. Expires August 15, 2003 [Page 1] Internet-Draft DNSSEC Introduction and Requirements February 2003 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 . . . . . . . . . . . . . . 6 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 6 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 7 4. Services Not Provided by DNS Security . . . . . . . . . . . . 9 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 10 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 11 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 12 7.1 TTL values vs. SIG validity period . . . . . . . . . . . . . . 12 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 12 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 13 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 14 9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 14 9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 Normative References . . . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23Arends, et al. Expires August 15, 2003 [Page 2] Internet-Draft DNSSEC Introduction and Requirements February 20031. Introduction This document introduces the Domain Name System Security Extensions (DNSSEC). This document and its two companion documents ([13] and [14]) update, clarify, and refine the security extensions originally defined in RFC 2535 [3]. These security extensions consist of a set of new resource record types and modifications to the existing DNS protocol [2]. 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, 3008, 3090, 3225, 3226, and 3445, as well as several works in progress: "Redefinition of the AD bit", "Delegation Signer Resource Record", and "DNSSEC Opt-In". See [18] for more details on these documents. 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 protection against other types of attack, nor do they provide confidentiality.Arends, et al. Expires August 15, 2003 [Page 3] Internet-Draft DNSSEC Introduction and Requirements February 20032. Definitions of Important DNSSEC Terms authentication chain: In the DNSSEC model, a KEY RR signs a DS RR, which hashes one RR in another KEY RRset, which in turn signs another DS RR, which hashes one RR in yet another KEY RRset, and so forth, finally ending, if all goes well, with a KEY RR which signs whatever DNS data the end user was looking for in the first place. This alternating succession of KEY RRsets and DS RRs forms a chain of signed data, with each link in the chain vouching for the next. If a signature somewhere in this chain has been generated by an authentication key known to a security-aware resolver, then the resolver can attempt to verify and authenticate the signed chain of KEY and DS RRs from that point down to the target data. authentication key: A public key which a security-aware resolver trusts and can therefore use to verify data. A security-aware resolver can discover trusted authentication keys in three ways. First, the resolver is generally preconfigured to know about at least one key which it should trust. Second, the resolver may be able to discover both a new key and an associated DS RR which contains a valid hash of the new key and which has been signed by a key which the resolver trusts. Third, the resolver may be able to determine that a new key has been signed by another key which the resolver trusts. Note that the resolver must always be guided by local policy when deciding whether to trust a new key, even if the local policy is simply to trust any new key for which the resolver is able verify the signature. key signing key: An authentication key which is used to sign one or more other authentication keys. 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 itself does not distinguish between key signing keys and other DNSSEC authentication keys. Key signing keys are discussed in more detail in [12]. security-aware name server: An entity acting in the role of a name server (defined in section 2.4 of [1]) 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 [4] message size extension and the DO bit [8], and supports the RR types and message header bits defined in this document set.Arends, et al. Expires August 15, 2003 [Page 4] Internet-Draft DNSSEC Introduction and Requirements February 2003 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 [1]) 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 [4] message size extension and the DO bit [8], 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 resolver (defined in section 2.4 of [1]) which has at least a minimal understanding the DNS security extensions defined in this document set, but 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 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. Note that the distinction between security-aware resolvers and security-aware stub resolvers is different from the distinction between iterative-mode and recursive-mode resolvers in the base DNS specification: a particular security-aware resolver may operate exclusively in recursive mode, but still performs its own DNSSEC signature validity checks, while a security-aware stub resolver does not, by definition. security-oblivious: The opposite of "security-aware". signed zone: A zone whose RRsets are signed and which contains properly constructed KEY, SIG, NXT and (optionally) DS records. unsigned zone: The opposite of a "signed zone". 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 KEY 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.Arends, et al. Expires August 15, 2003 [Page 5] Internet-Draft DNSSEC Introduction and Requirements February 20033. 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 minor changes to the DNS protocol. DNSSEC adds four new resource record types (SIG, KEY, DS and NXT) 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 [4]. Finally, DNSSEC requires support for the DO bit [8], 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 [11].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 SIG 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 [7], 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 KEY 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 resolver or must have been learned and verified previously. Therefore, theArends, et al. Expires August 15, 2003 [Page 6] Internet-Draft DNSSEC Introduction and Requirements February 2003 resolver must be configured with at least one 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. 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 authentication chain specified in the original DNS security extensions proceeded from signed KEY record to signed KEY record, as necessary, and finally to the queried RRset. The current specification adds a new Delegation Signer (DS) RR type to simplify 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 KEY RRset at the child zone's apex. The child zone, in turn, uses one or more of the keys in this KEY RRset to sign its zone data. The authentication chain is therefore KEY->[DS->KEY]*->RRset, where "*" denotes zero or more DS- >KEY subchains. This authentication chain is normally constructed from the root of the DNS hierarchy down to the leaf zones, and is normally based on preconfigured knowledge of the public key for the root. Local policy, however, may also allow a security-aware resolver to trust one or more preconfigured keys other than the root key, or may not provide preconfigured knowledge of the root key, or may even prevent the resolver from trusting 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, but authentication and trust, in the final analysis, are matters 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 NXT record. The NXT 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 NXT records require a canonical representation and ordering for domain names in zones. Chains of NXT records explicitly describe the gaps, or "empty space", between domain names in a zone, as well as listingArends, et al. Expires August 15, 2003 [Page 7] Internet-Draft DNSSEC Introduction and Requirements February 2003 the types of RRsets present at existing names. Each NXT record is signed and authenticated using the mechanisms described in Section 3.1.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -