📄 draft-ietf-dnsext-dnssec-protocol-07.txt
字号:
DNS Extensions R. ArendsInternet-Draft Telematica InstituutExpires: January 13, 2005 M. Larson VeriSign R. Austein ISC D. Massey USC/ISI S. Rose NIST July 15, 2004 Protocol Modifications for the DNS Security Extensions draft-ietf-dnsext-dnssec-protocol-07Status 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 This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are aArends, et al. Expires January 13, 2005 [Page 1] Internet-Draft DNSSEC Protocol Modifications July 2004 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 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 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Signature Verification Support . . . . . . . . . . . . . . 19 4.3 Determining Security Status of Data . . . . . . . . . . . 20 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23Arends, et al. Expires January 13, 2005 [Page 2] Internet-Draft DNSSEC Protocol Modifications July 2004 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 5.1 Special Considerations for Islands of Security . . . . . . 26 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 5.3.4 Authenticating A Wildcard Expanded RRset Positive Response . . . . . . . . . . . . . . . . . . . . . . . 31 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . 57Arends, et al. Expires January 13, 2005 [Page 3] Internet-Draft DNSSEC Protocol Modifications July 20041. Introduction The DNS Security Extensions (DNSSEC) are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document defines the DNSSEC protocol modifications. Section 2 of this document defines the concept of a signed zone and lists the requirements for zone signing. Section 3 describes the modifications to authoritative name server behavior necessary to handle signed zones. Section 4 describes the behavior of entities which include security-aware resolver functions. Finally, Section 5 defines how to use DNSSEC RRs to authenticate a response.1.1 Background and Related Documents The reader is assumed to be familiar with the basic DNS concepts described in [RFC1034] and [RFC1035]. This document is part of a family of documents that define DNSSEC. An introduction to DNSSEC and definition of common terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be familiar with this document. 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].Arends, et al. Expires January 13, 2005 [Page 4] Internet-Draft DNSSEC Protocol Modifications July 20042. 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. DNSSEC specifies the placement of two new RR types, NSEC and DS, which can be placed at the parental side of a zone cut (that is, at a delegation point). This is an exception to the general prohibition against putting data in the parent zone at a zone cut. Section 2.6 describes this change.2.1 Including DNSKEY RRs in a Zone To sign a zone, the zone's administrator generates one or more public/private key pairs and uses the private key(s) to sign authoritative RRsets in the zone. For each private key used to create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR containing the corresponding public key. A zone key DNSKEY RR MUST have the Zone Key bit of the flags RDATA field set -- see Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys associated with other DNS operations MAY be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT be used to verify RRSIGs. If the zone administrator intends a signed zone to be usable other than as an island of security, the zone apex MUST contain at least one DNSKEY RR to act as a secure entry point into the zone. This secure entry point could then be used as the target of a secure delegation via a corresponding DS RR in the parent zone (see [I-D.ietf-dnsext-dnssec-records]).2.2 Including RRSIG RRs in a Zone For each authoritative RRset in a signed zone, there MUST be at least one RRSIG record that meets all of the following requirements: o The RRSIG owner name is equal to the RRset owner name; o The RRSIG class is equal to the RRset class; o The RRSIG Type Covered field is equal to the RRset type; o The RRSIG Original TTL field is equal to the TTL of the RRset; o The RRSIG RR's TTL is equal to the TTL of the RRset; o The RRSIG Labels field is equal to the number of labels in the RRset owner name, not counting the null root label and notArends, et al. Expires January 13, 2005 [Page 5] Internet-Draft DNSSEC Protocol Modifications July 2004 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.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -