DNS Extensions R. Arends Internet-Draft Telematica Instituut Expires: March 30, 2004 M. Larson VeriSign R. Austein ISC D. Massey USC/ISI S. Rose NIST September 30, 2003 Protocol Modifications for the DNS Security Extensions draft-ietf-dnsext-dnssec-protocol-02 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 March 30, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document is part of a family of documents which describes 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 March 30, 2004 [Page 1] Internet-Draft DNSSEC Protocol Modifications September 2003 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 . . . . . . . . . . . . . . . . . . 8 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 9 3.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10 3.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 10 3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not Present . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches . . . 11 3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches . . . . . 11 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 12 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 12 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 13 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 14 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 15 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 21 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 22 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 24 5.1 Special Considerations for Islands of Security . . . . . . . 25 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 25 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 26 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 27 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 29 5.3.4 Authenticating A Wildcard Expanded RRset Positive Arends, et al. Expires March 30, 2004 [Page 2] Internet-Draft DNSSEC Protocol Modifications September 2003 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 30 5.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5.1 Example of Re-Constructing the Original Owner Name . . . . . 31 5.5.2 Examples of Authenticating a Response . . . . . . . . . . . 32 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . 34 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 Normative References . . . . . . . . . . . . . . . . . . . . 36 Informative References . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 39 B. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . 46 Arends, et al. Expires March 30, 2004 [Page 3] Internet-Draft DNSSEC Protocol Modifications September 2003 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 March 30, 2004 [Page 4] Internet-Draft DNSSEC Protocol Modifications September 2003 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 March 30, 2004 [Page 5] Internet-Draft DNSSEC Protocol Modifications September 2003 2. Zone Signing DNSSEC is built around 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. Any zone which does not include these records according to the rules in this section MUST be considered unsigned for the purposes of the DNS security extensions. DNSSEC requires a change to the definition of the CNAME resource record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs to appear at the same owner name as a CNAME RR. Section 2.6 shows a sample signed zone. 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 stored in the zone. A zone key DNSKEY RR has 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. 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]). This DNSKEY RR SHOULD be either a zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro] for definition). The DNSKEY RRset at the zone apex MUST be signed by at least one zone signing or DNSKEY signing private key. DNSKEY RRs MUST NOT appear at delegation points. 2.2 Including RRSIG RRs in a Zone For each authoritative RRset in a signed zone (which excludes both NS RRsets at delegation points and glue RRsets), 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; Arends, et al. Expires March 30, 2004 [Page 6] Internet-Draft DNSSEC Protocol Modifications September 2003 o The RRSIG Type Covered field is equal to the RRset type; o The RRSIG Original TTL field is equal to the TTL of the RRset; o The RRSIG RR's TTL is equal to the TTL of the RRset; o The RRSIG Labels field is equal to the number of labels in the RRset owner name, not counting the null root label and not counting the wildcard label if the owner name 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 which appears at the zone apex name MUST be signed, but the NS RRsets which appear at delegation points (that is, the NS RRsets in the parent zone which delegate the name to the child zone's name servers) MUST NOT be signed. Glue address RRsets associated with delegations MUST NOT be signed. The difference between the set of owner names which require RRSIG records and the set of owner names which 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 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.3 Including NSEC RRs in a Zone Each owner name in the zone MUST have an NSEC resource record, except for the owner names of any glue address RRsets. The process for Arends, et al. Expires March 30, 2004 [Page 7] Internet-Draft DNSSEC Protocol Modifications September 2003 constructing the NSEC RR for a given name is described in [I-D.ietf-dnsext-dnssec-records]. 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. 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 key used by the child zone to sign its apex DNSKEY RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT appear at non-delegation points nor 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. 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. 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 co-exist 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 co-exist with NSEC and RRSIG RRs. 2.6 Example of a Secure Zone Appendix B shows a complete example of a small signed zone. Arends, et al. Expires March 30, 2004 [Page 8] Internet-Draft DNSSEC Protocol Modifications September 2003 3. Serving This section describes the behavior of a security-aware authoritative name server. A security-aware authoritative 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]. Since functions specific to security-aware recursive name servers included components of both resolving and serving, issues specific to security-aware recursive name servers are described in Section 4. Upon receiving a relevant query which 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 which can be used to authenticate a response MUST be included in the response according to the rules in Section 3.1; o NSEC RRs which can be used to provide authenticated denial of existence MUST be included in the response automatically according to the rules in Section 3.3; o Either DS RRs or an NSEC RR proving that no DS RRs exist MUST be included in referrals automatically according to the rules in Section 3.4. DNSSEC does not change the DNS zone transfer protocol. Zone transfer requirements are reviewed in Section 3.6. A security-aware name server which receives a DNS query which does not include the EDNS OPT pseudo-RR or which 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 above. 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.5. 3.1 Including RRSIG RRs in a Response When a query has the DO bit set to one, the authoritative name server SHOULD attempt to send RRSIG RRs which can be used 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 Arends, et al. Expires March 30, 2004 [Page 9] Internet-Draft DNSSEC Protocol Modifications September 2003 which 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 these RRSIG RRs, the name server MUST NOT set the TC bit solely because these RRSIG RRs didn't fit. 3.2 Including DNSKEY RRs In a Response When a query has the DO bit set to one and 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 DNSKEY RRset with the same name in the Additional section. In this situation, the DNSKEY RR set and associated RRSIG RRs have lower priority than any other information that would be placed in the additional section. The name server should include the DNSKEY RRset if and only if there is enough space in the response for both the DNSKEY RRset and 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. 3.3 Including NSEC RRs In a Response When a query has the DO bit set to one, security-aware authoritative name servers for a signed zone MUST include NSEC RRs in each of the following cases: Case 1: The QNAME has RRsets associated with it in the zone, but the requested RR type does not exist. Case 2: The QNAME, QTYPE, QCLASS tuple does not exist, and no wildcard can be expanded to answer the query. Case 3: The QNAME (or search name) does not exist, but a wildcard can be expanded to positively answer the query. Note that, in each case, a set of NSEC RRs is included to provide authenticated denial of existence. Arends, et al. Expires March 30, 2004 [Page 10] Internet-Draft DNSSEC Protocol Modifications September 2003 3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not Present If there are RR types associated with a given QNAME, but the requested RR type is not present at the name, then the name server MUST include the NSEC RR associated with the query name and any RRSIG RRs associated with the NSEC RR in the Authority section (see Section 3.1). If space does not permit inclusion of the NSEC RR or its associated RRSIG RRs, the name server MUST set the TC bit. Note that, since the query name exists, no wildcard expansion applies to this query, and a single NSEC RR suffices to prove the requested RR type does not exist. 3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches If the query name does not exist in the zone, and no wildcard expansion matches both the query name and the query type, 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 was no exact match for the name; and o An NSEC RR combination proving that there was no wildcard which would have matched the query. See [I-D.ietf-dnsext-wcard-clarify] for further information on NSEC coverage. If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1). Appendix A provides an algorithm which computes the appropriate NSEC RRs to prove that no wildcard matches a given query name. 3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches If the query name does not exist, but a wildcard expansion can be used to return a positive match to the query, the name server MUST include the wildcard-expanded answer and the corresponding wildcard-expanded RRSIG RRs in the Answer section. The Authority section of the response MUST include the following NSEC RRs along with their corresponding RRSIG RRs: o An NSEC RR which proves that there were no exact matches for the QNAME and QTYPE; and o An NSEC RR combination which proves that there are no closer wildcard entries which could have been expanded to match the query. See [I-D.ietf-dnsext-wcard-clarify] for further information on NSEC coverage. Arends, et al. Expires March 30, 2004 [Page 11] Internet-Draft DNSSEC Protocol Modifications September 2003 If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1). Appendix A provides an algorithm which computes the appropriate NSEC RRs to prove that no closer wildcard matches the query name. 3.4 Including DS RRs In a Response When a query has the DO bit set to one, and a DS RR exists at the query name, an authoritative security-aware name server returning a referral for the delegation MUST include both the NS RRset and also the DS RRset and its associated RRSIG RR(s). The name server MUST place the NS RRset before the DS RRset and its associated RRSIG RRs. When a query has the DO bit set to one, and no DS RR exists at the query name, an authoritative security-aware name server returning a referral for the delegation MUST include both the NS RRset and also the NSEC RR and associated RRSIG RR(s) which proves that the DS RRset does not exist. The name server MUST place the NS RRset before the NSEC RRset and its associated RRSIG RR(s). Including these DS 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. Security-aware name servers also include NSEC RRs in a referral response when no DS RR is present; in this case, the NSEC RR proves that no DS RR exists for the delegation. Section 3.4 discusses referrals in more detail. 3.5 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. In other words, the DS record for the delegation of "example.com" is only stored in the "com" zone. This introduces novel name server behavior, since the name server for the child zone is authoritative for the name by the normal DNS rules but the child zone does not contain the DS RR. An authoritative name server's response to a DS query depends on whether the name server is authoritative for the parent zone, the child zone, or both, as described below. If a name server is authoritative for the parent zone, and receives a query for the DS record at the delegated name, then the name server MUST return the DS RRset from the parent zone. This rule applies regardless of whether or not the name server is also authoritative for the child zone. Arends, et al. Expires March 30, 2004 [Page 12] Internet-Draft DNSSEC Protocol Modifications September 2003 If the name server is authoritative for the child zone, is not authoritative for the parent zone, and receives a query for the DS record at the delegated name, there is no obvious response, because the child zone is not authoritative for the DS record at the child zone's apex, and the authoritative DS RR is only stored at the parent. If the name server allows recursion, and the RD bit is set in the query, the name server MAY perform recursion to find the DS record for the delegated name from the parent zone, and MAY return the DS record from its cache. In this case, the AA bit MUST NOT be set in the response. If the name server does not perform recursion to find the DS RR, the name server MUST reply with: RCODE: NOERROR AA bit: set Answer Section: Empty Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)] In other words, a name server which is authoritative for the child zone but not for the parent zone answers as if the DS record does not exist. Note that security-aware resolvers will query the parent zone at delegation points, and thus will not be affected by this behavior. For example, suppose that "example.com" is a delegation point, and a name server receives a query for the "example.com" DS RRset. o If the name server is authoritative for "com", the name server MUST reply with the "example.com" DS RRset from the "com" zone. o If the name server is authoritative for "example.com", is not authoritative for "com", and the RD bit is set to one in the query, the name server MAY perform recursion to find the "example.com" DS record. If the name server does not use recursion to obtain the DS RR, the name server MUST reply as though the DS RR did not exist: RCODE: NOERROR AA bit: set Answer Section: Empty Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)] 3.6 Responding to Queries for Type AXFR or IXFR DNSSEC does not change the DNS zone transfer process. A signed zone Arends, et al. Expires March 30, 2004 [Page 13] Internet-Draft DNSSEC Protocol Modifications September 2003 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. Note that the DS RR appears only in the 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). As with any other authoritative RRset, the "example.com" DS RR MUST be included the "com" zone transfer. Note that authoritative NSEC RRs appear in both the parent and child zones at a delegated name, and that the NSEC RRs for the delegated name in the parent and child zones are never identical to each other. As with any other authoritative RRset, the parental NSEC RR at a delegated name MUST be included zone transfers of the parent zone, while the NSEC at the zone apex of the child zone MUST be included in zone transfers of the child zone. 3.7 Setting the AD and CD Bits in a Response Editors' note: This section seems a little lost here. Perhaps we should rearrange the section ordering slightly, or provide a pointer to this subsection at the beginning of Section 3. 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 set in query messages by the resolver, and MUST be copied into the response by the name server. If the CD bit is set to one, it indicates that the resolver is willing to perform whatever authentication its local policy requires, and thus that the name server need not perform authentication on the RRsets in the response. Regardless of the setting of the CD bit, the name server MAY choose whether or not to perform authentication according to its own local name server policy, and the name server MAY use the CD bit as input Arends, et al. Expires March 30, 2004 [Page 14] Internet-Draft DNSSEC Protocol Modifications September 2003 to its own local policy. However, if the resolver has set the CD bit, a name server SHOULD, if possible, return the requested data to the resolver even if the name server's local authentication policy would reject the records in question. That is, by setting the CD bit, the resolver has taken responsibility for performing its own authentication, and the name server should not interfere in this case. The AD bit is set by name servers, and indicates the data in the response has been authenticated by the name server, according to the local name server policy. The AD bit MUST NOT be set on a response unless all of the RRsets in the Answer and Authority sections have met the name server's local authentication policy. A resolver MUST NOT trust the AD bit unless it communicates with the name server over a secure transport mechanism and is explicitly configured to trust the name server's policy. 3.8 Example DNSSEC Responses Editors' note: these examples probably ought to move to an appendix and probably ought to use the "real" signed example zone that's already in an appendix. The examples in this section use the following example zone to demonstrate the formation of replies by an authoritative name server. The zone has two name servers, a single child, and a wildcard MX RR. The zone is completely signed and has a full NSEC chain. example.com. SOA (...) RRSIG SOA ... NS a.example.com. NS b.example.com. RRSIG NS ... MX 10 a.example.com RRSIG MX ... DNSKEY ... RRSIG DNSKEY ... NSEC *.example.com. * MX 10 a.example.com. RRSIG MX ... NSEC a.example.com. a A 10.10.10.1 RRSIG A ... NSEC b.example.com. b A 10.10.10.2 RRSIG A ... NSEC c.example.com. c CNAME a.example.com. Arends, et al. Expires March 30, 2004 [Page 15] Internet-Draft DNSSEC Protocol Modifications September 2003 RRSIG CNAME NSEC sub.example.com. sub NS ns.sub.example.com. RRSIG NS DS ... RRSIG DS NSEC *.example.com. ns.sub A 10.10.10.3 sub-nosig NS ns.sub-nosig.example.com. NSEC example.com. ns.sub-nosig A 10.10.10.4 A query to the authoritative name server for this zone for QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce: Flags: QR=1, AA=1, RCODE=0 (NOERROR) EDNS: DO=1, size=4000 QUERY: c.example.com. IN A ANSWER: c.example.com. IN A a.example.com IN RRSIG CNAME a.example.com. IN A 10.10.10.1 IN RRSIG A AUTHORITY: example.com. IN NS a.example.com. IN NS b.example.com. IN RRSIG NS ... ADDITIONAL: a.example.com. IN A 10.10.10.1 IN RRSIG A ... b.example.com. IN A 10.10.10.2 IN RRSIG A ... A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would results in a referral to a signed zone. The resolver can determine that "sub.example.com" is signed because of the presence of the DS RR with the hash of the "sub.example.com" zone key. Flags: QR=1, AA=1, RCODE=0 (NOERROR) EDNS: DO=1, size=4000 QUERY: www.sub.example.com. IN A ANSWER: ;; empty AUTHORITY: sub.example.com. IN NS ns.sub.example.com. IN DS ... Arends, et al. Expires March 30, 2004 [Page 16] Internet-Draft DNSSEC Protocol Modifications September 2003 IN RRSIG DS ... ADDITIONAL: ns.sub.example.com. IN A 10.10.10.3 A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A would result in a referral to an unsigned zone. The resolver knows not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS bit in the NSEC RR bitmap in the referral is not set. Even if DNSSEC RRs are present in responses from "sub-nosig.example.com" name servers, the resolver will not be able to construct a authentication chain, since there is a break between "sub-nosig.example.com" and its delegating parent zone. Flags: QR=1, AA=1, RCODE=0 (NOERROR) EDNS: DO=1, size=4000 QUERY: www.sub-nosig.example.com. IN A ANSWER: ;; empty AUTHORITY: sub-nosig.example.com. IN NS ns.sub-nosig.example.com. IN NSEC ;; (DS bit not set) IN RRSIG NSEC ... ADDITIONAL: ns.sub-nosig.example.com. IN A 10.10.10.4 A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name error, because the name does not exist and is not covered by wildcard expansion. Therefore, the name server must present proof that the name does not exist, and that no wildcard expansion is present which could have been used to answer the query. Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN) EDNS: DO=1, size=4000 QUERY: f.example.com. IN A ANSWER: ;; empty AUTHORITY: example.com. IN SOA ... IN RRSIG SOA ... c.example.com. IN NSEC sub.example.com. ... IN RRSIG NSEC ... *.example.com. IN NSEC a.example.com. ... IN RRSIG NSEC ... ADDITIONAL: example.com. IN DNSKEY ... IN RRSIG DNSKEY ... Arends, et al. Expires March 30, 2004 [Page 17] Internet-Draft DNSSEC Protocol Modifications September 2003 A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX RR synthesized via wildcard expansion. The name server must prove that no exact match exists. Flags: QR=1, AA=1, RCODE=0 (NOERROR) EDNS: DO=1, size=4000 QUERY: f.example.com. IN MX ANSWER: f.example.com. IN MX 10 a.example.com. IN RRSIG MX ... AUTHORITY: example.com. IN NS a.example.com. IN NS b.example.com. IN RRSIG NS ... c.example.com. IN NSEC sub.example.com. IN RRSIG NSEC ... ADDITIONAL: a.example.com. IN A 10.10.10.1 IN RRSIG A ... b.example.com. IN A 10.10.10.2 IN RRSIG A ... If these responses came from a recursive name server which had all of the necessary RRsets in its cache instead of from an authoritative server, the only differences would be the TTLs and the header flags. The AA bit would not be set, and the AD bit would be set if (and only if) all the RRsets in a response passed the security policy checks of the recursive name server. Arends, et al. Expires March 30, 2004 [Page 18] Internet-Draft DNSSEC Protocol Modifications September 2003 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 a separate subsection. 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. 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. 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. A security-aware resolver MUST attempt to retrieve missing a 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 does know the name of the missing NSEC RR, and must therefore attempt to retrieve it. Arends, et al. Expires March 30, 2004 [Page 19] Internet-Draft DNSSEC Protocol Modifications September 2003 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 starting point 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 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. A security-aware resolver MUST be capable of being preconfigured with at least one trusted public key, and MUST 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. A security-aware resolver SHOULD cache each response as a single atomic entry, indexed by the triple , with the 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. 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 it generates, which may require the resolver to retain some data about recently generated queries. Conceptually, this is similar to negative caching [RFC2308], but since the resolver has no way of obtaining the appropriate caching TTL from received data in this case, the TTL will have to be set by the implementation. This document refers data retained as part of such a rate limiting mechanism as the "BAD cache". Arends, et al. Expires March 30, 2004 [Page 20] Internet-Draft DNSSEC Protocol Modifications September 2003 4.1 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. A security-aware recursive name server MUST NOT attempt to answer a query by piecing together cached data it received in response to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes. A security-aware recursive name server MUST NOT use NSEC RRs from one negative response to synthesize a response for a different query. A security-aware recursive name server MUST NOT use a previous wildcard expansion to generate a response to a different query. 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 whether or not it is required to verify the response data it returns to the name server side. 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 but MUST NOT strip any DNSSEC RRs that the initiating query explicitly requested. The resolver side MUST follow the usual rules for caching and negative caching which would apply to any security-aware resolver. If 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 setting 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 SHOULD return RCODE 2 (server failure). 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 or Authority sections of the response to be authentic, and SHOULD set the AD bit if and only if the name server considers all RRsets in the Answer section and any relevant negative Arends, et al. Expires March 30, 2004 [Page 21] Internet-Draft DNSSEC Protocol Modifications September 2003 response RRs in the Authority section to be authentic. How the name server side of a security-aware recursive name server determines whether an RRset is authentic depends on the origin of the RRset. If the RRset came from the resolver side of the recursive name server (the normal case), recursive name server MUST follow the procedure described in Section 5. If the RRset came from a zone for which the name server side of the recursive name server is authoritative, local policy MAY consider the RRset to be authentic without further verification simply because the RRset came from an authoritative zone, but the name server SHOULD NOT do so unless the it 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. 4.2 Stub resolvers A security-aware stub resolver MUST include an EDNS [RFC2671] OPT pseudo-RR with the DO [RFC3225] bit set to one when sending queries. A security-aware stub 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 stub 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. 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. A security-aware stub resolver MAY include the DNSSEC RRs returned by a security-aware recursive name server as part of the data that it the stub resolver hands back to the application which invoked it but is not required to do so. A security-aware stub resolver SHOULD NOT set the CD bit when sending queries, since, by definition, a security-aware stub resolver does not validate signatures and thus depends on the security-aware recursive name server to perform validation on its behalf. A 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 Arends, et al. Expires March 30, 2004 [Page 22] Internet-Draft DNSSEC Protocol Modifications September 2003 except perhaps as a debugging aid. In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel. Arends, et al. Expires March 30, 2004 [Page 23] Internet-Draft DNSSEC Protocol Modifications September 2003 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 has the Zone Key Flag (DNSKEY RDATA bit 7) set to one. 2. Verify that there is some RRSIG RR which 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, 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 which that lacks the appropriate DNSSEC RRs, whether due to configuration issues such as a security-oblivious recursive name server which accidentally Arends, et al. Expires March 30, 2004 [Page 24] Internet-Draft DNSSEC Protocol Modifications September 2003 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 a trusted zone key. 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 trusted 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 and the key tag of a DNSKEY RR in the child zone's apex DNSKEY Arends, et al. Expires March 30, 2004 [Page 25] Internet-Draft DNSSEC Protocol Modifications September 2003 RRset which, when hashed using the digest algorithm specified in the DS RR's Digest Type field, results in a digest value which 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.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 which 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 which 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. 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 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. Arends, et al. Expires March 30, 2004 [Page 26] Internet-Draft DNSSEC Protocol Modifications September 2003 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 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 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 which the resolver has been preconfigured to believe to be authentic. Arends, et al. Expires March 30, 2004 [Page 27] Internet-Draft DNSSEC Protocol Modifications September 2003 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 = RRset's fully qualified domain name in canonical form if rrsig_labels = fqdn_labels, name = fqdn if rrsig_labels < fqdn_labels, name = "*." | the leftmost rrsig_label labels of the fqdn Arends, et al. Expires March 30, 2004 [Page 28] Internet-Draft DNSSEC Protocol Modifications September 2003 if rrsig_labels > fqdn the RRSIG RR did not pass the necessary validation checks and MUST NOT be used to authenticate this RRset. Section 5.5.1 gives an example of original name calculation. 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 which 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 to generate the signature. The signature itself is contained in the Signature field of the RRSIG RDATA, and the public key to used generate the signature is contained in the Public Key field of the matching DNSKEY RR(s) (found in Section 5.3.1). [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types, and provides pointers to the documents that define each algorithm's use. Note that it is possible for more than one DNSKEY RR to match the Arends, et al. Expires March 30, 2004 [Page 29] Internet-Draft DNSSEC Protocol Modifications September 2003 conditions in Section 5.3.1. In this case, the resolver can only determine which DNSKEY RR by trying each matching 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 RRSIG RR, 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 fully qualified domain name is greater than the Labels field in the covering RRSIG RDATA, 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.3). 5.4 Authenticated Denial of Existence A resolver can use authenticated NSEC RRs to prove that an RRset is not present in a signed zone. Security-aware name servers should automatically include any necessary NSEC RRs for signed zones in their responses to security-aware resolvers. Arends, et al. Expires March 30, 2004 [Page 30] Internet-Draft DNSSEC Protocol Modifications September 2003 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. Since the existence of the authenticated NSEC RR proves that the owner name exists in the zone, wildcard expansion could not have been used to match the requested RR owner name and type. o If the requested RR name would appear after an authenticated NSEC RR 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 exact match for the requested RR name exists 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 exists which 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 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 existance 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 Examples Editors' note: perhaps all of this should move to an appendix? 5.5.1 Example of Re-Constructing the Original Owner Name Suppose that a security-aware resolver receives a response containing an answer RRset with an owner name of is "www.a.b.c.example.com". This fully qualified domain name has 6 labels: "www", "a", "b", "c", Arends, et al. Expires March 30, 2004 [Page 31] Internet-Draft DNSSEC Protocol Modifications September 2003 "example", and "com". What name the resolver should use when reconstructing the original signed data depends on the value of the RRSIG RR's Labels field. If the value of the RRSIG RR's Labels field is 6, then the RRSIG RR's Labels field matches the number of labels in the owner name, and the resolver should assume that this RRset is not the result of wildcard expansion. The resolver should therefore use "www.a.b.c.example.com" as the owner name when reconstructing the original signed data for the signature check. If the value of the RRSIG RR's Labels field is less than 6, then the RRSIG RR's Labels count is less than the number of labels in the RRset's owner name, and the resolver should assume that this RRset is the result of wildcard expansion. The resolver should therefore reconstruct the original owner name by replacing the labels which appear to be the result of wildcard expansion with a single "*." label. For example, if the RRSIG RR's Labels field is 3, the resolver should reconstruct the original owner name by prepending "*." to the last 3 labels of the owner name of the answer RRset. Thus, the resolver should use "*.c.example.com" as the owner name when reconstructing the original signed data. If the value of the RRSIG RR's Labels field is greater than 6, then this RRSIG RR cannot possibly be valid for the answer RRset, and there is no point in attempting to validate the signature. 5.5.2 Examples of Authenticating a Response Editors' note: Eventually this will be an example of the authentication process for "www.example.com", starting from an initial root key. Editors' note: Eventually this will be an example of the authentication process for non-existent "www.a.b.c.example.com", starting from an initial root key. Arends, et al. Expires March 30, 2004 [Page 32] Internet-Draft DNSSEC Protocol Modifications September 2003 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 [I-D.ietf-dnsext-ad-is-secure] 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 March 30, 2004 [Page 33] Internet-Draft DNSSEC Protocol Modifications September 2003 7. Security Considerations This document describes how the DNS security extensions use public key cryptography to sign and authenticate DNS resource record sets. DNSSEC introduces a number of denial of service issues. These issues will also be addressed in a future version of these security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] for general security considerations related to DNSSEC. Arends, et al. Expires March 30, 2004 [Page 34] Internet-Draft DNSSEC Protocol Modifications September 2003 8. Acknowledgements This document was created from the input and ideas of several members of the DNS Extensions Working Group and working group mailing list. The co-authors of this draft would like to express their thanks for the comments and suggestions received during the revision of these security extension specifications. Arends, et al. Expires March 30, 2004 [Page 35] Internet-Draft DNSSEC Protocol Modifications September 2003 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-06 (work in progress), September 2003. [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-04 (work in progress), September 2003. Arends, et al. Expires March 30, 2004 [Page 36] Internet-Draft DNSSEC Protocol Modifications September 2003 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. [I-D.ietf-dnsext-delegation-signer] Gudmundsson, O., "Delegation Signer Resource Record", draft-ietf-dnsext-delegation-signer-15 (work in progress), June 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-01 (work in progress), August 2003. [I-D.ietf-dnsext-ad-is-secure] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit", draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002. Authors' Addresses Roy Arends Telematica Instituut Drienerlolaan 5 7522 NB Enschede NL EMail: roy.arends@telin.nl Arends, et al. Expires March 30, 2004 [Page 37] Internet-Draft DNSSEC Protocol Modifications September 2003 Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA EMail: mlarson@verisign.com Rob Austein Internet Software Consortium 40 Gavin Circle Reading, MA 01867 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 March 30, 2004 [Page 38] Internet-Draft DNSSEC Protocol Modifications September 2003 Appendix A. Algorithm For Handling Wildcard Expansion For zone (Z) and a name (N) that may occur in Z, the following algorithm finds all wildcard RRsets that match N or returns an NSEC RRset that proves no wildcard expansion matches N. The algorithm was written for clarity, not efficiency: 0. INPUT: a name (N) and a zone (Z). INIT: NSEC_SET = NULL 1. Construct S = sequence of all names in Z, sorted into canonical order. 2. If N exists in S There is an exact match for N. Return all RRsets associated with N Else Add the name that would immediately precede N in S to NSEC_SET. EndIf 3. Replace the leftmost label of N with * 4. If N exists in S and answers the query There is a positive wildcard match for N. Return all RRsets associated with N Else Add the NSEC for name that would immediately precede N in S to NSEC_SET. Return the NSEC_SET. EndIf 5. Remove the leading * from N. 6. If N exists in S There is a name that terminates the wildcard search. Add the NSEC for N to NSEC_SET and return NSEC_SET. Else Add the NSEC for name that would immediately precede N in S to NSEC_SET. Return the NSEC_SET. EndIf Arends, et al. Expires March 30, 2004 [Page 39] Internet-Draft DNSSEC Protocol Modifications September 2003 Appendix B. Signed Zone Example The following example shows a (small) complete signed zone. example. 3600 IN SOA ns1.example. bugs.ns1.example. ( 1064876255 3600 300 3600000 3600 ) 3600 RRSIG SOA 1 1 3600 20031029215736 ( 20030929215736 4638 example. Bo6PBV6UOrnCzptCZg0lTQQqsZ4qqIn16vbA KQobYD2wNxs5hxNYlvNRlNPB0nfSD9o2daBE v0Q/Q5mEanr2R28a62PHwkHNwHUx/spGWAGJ h5u28d5wMNQQvMsFgB+kSSnNEcL1Z7uLjRal ahgGvtiSMzzSS7n65xfxc1X78Nw= ) 3600 NS ns1.example. 3600 NS ns2.example. 3600 RRSIG NS 1 1 3600 20031029215736 ( 20030929215736 4638 example. WeJdApmzK+GIrOQKYmkABF5POWu5SDU6opwd wOjWrVFGRNhFHe1Z/KZwT1Ii5YjH2X9dTRRh YG3U/wcqvWLJ1882FoUZakwmtzGFotdONcs3 DzhFMxTawVlBb+MLsPj8J2GuZiR28eTyPB6i TYq3Ed0R9VStJwtiKmoXqubFAr0= ) 3600 MX 1 xx.example. 3600 RRSIG MX 1 1 3600 20031029215736 ( 20030929215736 4638 example. eBXNS2Vi/MhqX76VCIlpbK4yq9UWzvYcSBV9 Cx0t6rl9CWOpdFVzV/lL0wyVYQjZXBlZ1gpo djLXl0QTEE+9MrRO3c8j7NyVsOEJQdnWdEAW BL8f+F3fwayjj5dIsq1NngF8neGXROao1bJM 5gmIc/F6gzUL3/KyJA8zPF2fUVA= ) 3600 NSEC a.example. NS SOA MX RRSIG NSEC 3600 RRSIG NSEC 1 1 3600 20031029215736 ( 20030929215736 4638 example. t3VabTtmQ3uEgohzbuHKk2bFEDqYWa3hgTi2 D1Sv+eN+IkV1xExBvsvuE6Oovf+QlDqV7sU/ XP2kRzob5V9N40xQCZMBFx2GgAim8px788EX ZuS7u0fKeHfaP/2sSTktGnpK77Mx4fM6RK8x DBRONckIWXn2chGDeicQuEHjhfQ= ) 3600 DNSKEY 256 3 1 ( AQPbGuRKgswzNd2Qb7ck1Tdai9FFbapP3mUO G80mSowM5s9aMao+JOeFl/4f33cs2hWHznn3 LZ5EuIlA/lvvG+f5h46OvCR+CFXHmqEPyMmd kiCdJmHcvRuMIzekHM2DSDcG7i1lZG/jXvaG Arends, et al. Expires March 30, 2004 [Page 40] Internet-Draft DNSSEC Protocol Modifications September 2003 mK5G3NeHjqssh1AujDaqHFf5IRIeQQ== ) 3600 DNSKEY 257 3 1 ( AQPGkQLwyHHfD8nkDxZSbErTBHLYdOKkVIoq SJkBnpfABtFdiJBgZYcjCNExAFjlc/olW42g TJYBRjs1INw3I08/h43L595Iq8fyhEyBoGOR +6db+Q3oQ9G2EKpfMEPDLU6f7gYrHpzDHIjO rsSftzmRYHou70oVQ7aBjd9ePPCOVw== ) 3600 RRSIG DNSKEY 1 1 3600 20031029215736 ( 20030929215736 4638 example. GMZI2r4bwFYpKIs0Dv//4aWg5HhpzMBkm5Vk 4KFg4hEkOabYgWoBJdZdjRBTrjwkrtiPH9KF kJKlzFfeeELbFEfhgZ3SujDqNQmGfoZ1i7a2 lH47jc1JOeos75e9QK8fUFjIxOF8fkZNO9Fx lOyOxNDJPATE3Wm+AX0SmQSJ3XY= ) a.example. 3600 IN NS ns1.a.example. 3600 IN NS ns2.a.example. 3600 DS 23677 1 1 ( F248F32298280A061736C93FB078A51C17CC C291 ) 3600 RRSIG DS 1 2 3600 20031029215736 ( 20030929215736 4638 example. k6fA3VfeR5UHu9L/+4y8HJrUubVHBdyFzMaa 8EpDYqw3vYEVsrL5YvXwoqrSZsSAxdIrUXoB SzjbKFOq6HRxXjuLsJ2TLT90p6mg9ZHL57jH FfmrNPuq58QwRWvwuOyaExJWEdxMIEIbvETz YJs3G/9tNte9i25YtAuLHbD2UqY= ) 3600 NSEC ai.example. NS DS RRSIG NSEC 3600 RRSIG NSEC 1 2 3600 20031029215736 ( 20030929215736 4638 example. tQbGVL6yxb2vBQ5ItcQ1XQyxNxz3+zHTTkgs T/WSk9YXr+swug7h+Wq20RPXfsEl7lVMi/By d60s6Q7lEibGucIQCLLx0Xe68zQOmWx7fmU6 iSDTQgc7TOsG/blDba7MiRENTeI6iynyZHw9 gURpK8RlfEPb7O98rrYLWZbzg3o= ) 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 1 2 3600 20031029215736 ( 20030929215736 4638 example. UCegsbGngHOwgyxevtBrCSsV6Jv6OxGWApvY RsbwL2XZBFc4saU6Zujiz8i2urkVLSlFM2MM OHuEMN5E+cjGDjqfaI8O5eILapsGRqHUPM9t 5wCOb9BqANn03UUFUhAnKBkv3fHFM5hg+IZQ vVNUzslGEBlQ0SJZkWJcCtRDo5c= ) 3600 HINFO "KLH-10" "ITS" 3600 RRSIG HINFO 1 2 3600 20031029215736 ( Arends, et al. Expires March 30, 2004 [Page 41] Internet-Draft DNSSEC Protocol Modifications September 2003 20030929215736 4638 example. CP6bRkIyQ3FnhsBWO63uQN1QtJse8mWNRTf2 jXqR33dekEfKNhlQtw0yzepa7lX75uyQTAlP NBBK73Zlim5g1bw3ulLl0vXnTpQRSK80SJw9 uPPTYBDq68jMKn1a3RvGnR5MynQR33UY2vGT 6IAiGfqY/zYFXWSIsmJr0875PQ0= ) 3600 AAAA 2001:db8::f00:baa9 3600 RRSIG AAAA 1 2 3600 20031029215736 ( 20030929215736 4638 example. VnpRe+HGt+mCalDopO4wtHtRvs9CKdjr3FoG zv8BPFvC1FdDJAjxpAgJs6Ihx+174Hl+jlZU Z3HOd0MBwch0XH1UDcU0/opQRquW+oYwV3E4 esgKhsy9EUj3NtoW/GQ/1dJEbuUZah4/IPGH KI0DhRWJC/iKs6J963WLNdPnwKk= ) 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 1 2 3600 20031029215736 ( 20030929215736 4638 example. A7MtS+oATUFf6t3nj/0GL7lBbt86ozzkbbJM J3tLwFkGebf1XV+MnpPeSzeRXm4QeqohDvVZ U5SluyOHT397x4WQPwHCRXojos1lQnWhPUji qjKaXLVRHv4x2O2fzWu0OE65GJkL6zAnFqCL SpV8hBOC+EAcLjnuAi5DJJlONmc= ) b.example. 3600 IN NS ns1.b.example. 3600 IN NS ns2.b.example. 3600 NSEC ns1.example. NS RRSIG NSEC 3600 RRSIG NSEC 1 2 3600 20031029215736 ( 20030929215736 4638 example. lGZ+rJ1vtIEtLjXKG4Iruipq6KoXrre89QHZ dBgSPcomROrsSElhUBFLcl2+KMCnKCqtEJZ7 YPOTK07WCwFU6Rek+xD+OuuJrQRWTbiCmFMX N9ZMk87lkIWHAXMk1YM3f1/FUytbb8RI8RfH u2x/e3zoBQdHAId3LCOO9jYDzCc= ) 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 1 2 3600 20031029215736 ( 20030929215736 4638 example. u/uV4xcu7KSVV+3Vtg8O0qTGlGHeFKU1vBQJ x1QKLtolw/ZstzqIuRBI5fuF4JYxSwMoaI7b JBFyZ3KkCCK88r1VjZTkicNvFG7RO3G2faxb MualMbGfhcexJzRcoZsIXSb3+qtbAr4aKF7c fdZ587NLR1Ns2GraGTztUDMSK/A= ) 3600 NSEC ns2.example. A RRSIG NSEC 3600 RRSIG NSEC 1 2 3600 20031029215736 ( 20030929215736 4638 example. bsz0NVY6tQ0kmIpKOR3QHNEradwR39uNikey jQIr7TMOvNVDX6tVBNoDuKxUy6zHR5CS6oBs nN5OPPKEjTdOGWUfHavSZgZGT7b8xfL++Ahi Arends, et al. Expires March 30, 2004 [Page 42] Internet-Draft DNSSEC Protocol Modifications September 2003 Cgeg0ofB6Ext7KfeMkTrxP/8BsDMJm8R8Ome I2mIq/WvuXTr2XKcJDbxYIdSyss= ) ns2.example. 3600 IN A 192.0.2.2 3600 RRSIG A 1 2 3600 20031029215736 ( 20030929215736 4638 example. mCzjw1wydcnYx0d7kbPbJTXVw+FnksdLnTmq DrIdy269MeGL4AGJSV8g8Gt0Zbq3hGo6+/Tz S9VIp4QZtKgRZ1nlI0XQOlkASOLPjvo7hHRr PPiFqGyznqy9+QHdIalqTO4BOrfS3f5bIgJW IGUMRh8nFi+wnG09+OH46IlkB9s= ) 3600 NSEC *.w.example. A RRSIG NSEC 3600 RRSIG NSEC 1 2 3600 20031029215736 ( 20030929215736 4638 example. FS6W/8Na26DIs1DYB1Xhhxc1GyRlzj5XkG/3 pY6H6PQGc/nP6CVM1eHEkmvYAG8kWfk9ZdDZ 64cOb2tisSH1o7WMLg7hWUS5nnXyxyyj5/Gs n3CpVCDptq9JnQe+jjH0empKdbTYoeVIX8h/ 2aw1RkmYb4LbuhP0uwN/lZqQVik= ) *.w.example. 3600 IN MX 1 ai.example. 3600 RRSIG MX 1 2 3600 20031029215736 ( 20030929215736 4638 example. MHxP6z3ozpA9AICDnEW0T06o2GlIOtj0+oGm TC4nqveQj2QSKOEUNXgVaUkBTT9F/FIVy9q+ FAAe4SXnBcVpIvTVN2NhU4Jm9976hU8HTEfi EMlnhmn4vJ1qZ+DI1WgWK+iKSU/N6ShdN/Fi G7zd/X4PmuWIIYG+5IAzmtB2UJs= ) 3600 NSEC x.w.example. MX RRSIG NSEC 3600 RRSIG NSEC 1 2 3600 20031029215736 ( 20030929215736 4638 example. tXBqjlbdFl70S+dzovir86EQBHavroozeo4f Spsc9BlorSdTTSwbf7lh+GRIS0hCtaJxMFog 0XhGhO6sn1Yai3s7NeV6viQpy8gPfJ0wfr9Y H1nYv76o6oXX2KlGTJrd4J7f7Hxz2DsOWVoK w1LXOATBvP/kCRgmq4KdFNwTiBc= ) x.w.example. 3600 IN MX 1 xx.example. 3600 RRSIG MX 1 3 3600 20031029215736 ( 20030929215736 4638 example. p/BQOuDk4Wg3pZreH6kmxws0A1hNYIkJTTlP rHoI9T/HMfA50p/qnXQHxgYh1IDnsxjeswaE LL7B/q0QxmaT1/0wNbZTn58/rqDSpV43Qxjl QHK0fDgp6al4VNxvK+uIJIHO525jCH146BEC +tqUhrmtTxtItfpV/8Q7i6+B2bY= ) 3600 NSEC x.y.w.example. MX RRSIG NSEC 3600 RRSIG NSEC 1 3 3600 20031029215736 ( 20030929215736 4638 example. c2/unp4ewGHNJIOVKiw9O/aA+PfXJ5Thwjt4 EyleUaXFp01H5RkDVxMVicJEHcfslqfzF8XP M9pPTwU7DPAFrxXo71pMez/EqA3pnhxnUcEi Arends, et al. Expires March 30, 2004 [Page 43] Internet-Draft DNSSEC Protocol Modifications September 2003 lVextpfIxIZam0Oj5Q+nCLJJs95Q3I8E5J29 IgHVoBYahu8hE0DycgzLredhC5A= ) x.y.w.example. 3600 IN MX 1 xx.example. 3600 RRSIG MX 1 4 3600 20031029215736 ( 20030929215736 4638 example. nwe5rxko6mbV2f0edTn0/H1CbDd8T4ZHg2Wg Os3Lh5Rz092PVbAnbzCp4Y95MdPPwMUd3cKk h7tvjBJgPPBhAWufdv2uVcq2lnINs1+LsJH7 CtJobsu9LxcORCkcYEKG1bc4fInPPnuUnlXD JYEmK1UOpYTDRx+lKLRI5tLzKmc= ) 3600 NSEC xx.example. MX RRSIG NSEC 3600 RRSIG NSEC 1 4 3600 20031029215736 ( 20030929215736 4638 example. UjlRFPbR2LzHtiP+CDGsJnaSo0iyooOkZ2By vyqOGHg+0OudJ4/+VYC/8C0dJNRUzAAm17GG ox272n3P0BHERCeegWAFCjYCARhZwkfpq8sQ ynkJRjpFlkxgdSFiHDZOAQz/s0a9ZaFDKP27 rKbS4qvhL+dfOnPBPNI099W7EAw= ) xx.example. 3600 IN A 192.0.2.10 3600 RRSIG A 1 2 3600 20031029215736 ( 20030929215736 4638 example. irvnPlRadiUTTM3feA/mNNKnxRIRY7vZ0r3d foc+IgbvYJeHi8UYThPrinjF2SPcwQ29g+6h aFA8ne9ZpRwL1lEQ6U3OTGLKd1OtGCTizEmN fgmPU/wIUuNaR7AG4i6FekWhciHbrjfRF/NN zJKlxAUeVRQ2ufYCoSY7wa6cIV4= ) 3600 HINFO "KLH-10" "TOPS-20" 3600 RRSIG HINFO 1 2 3600 20031029215736 ( 20030929215736 4638 example. NL6VSnSkuPX41EgJChuPiVF9JzIsJ/p7pQ61 DG8oWhtZjTP1uYWdwHPMM3EDxQykJBwJShE9 5Mg7myUpRFAuLHZJZ35227AZ6+eo0UoikJSA opuXW50OLYARZTy4lRqSUU41B5Km1vvYaIoq hjNlRggyhvEmSNw4kvl5w99jqKg= ) 3600 AAAA 2001:db8::f00:baaa 3600 RRSIG AAAA 1 2 3600 20031029215736 ( 20030929215736 4638 example. wkkCfIYfNeQ2YK0fL/bceo9oONGfZNkp/MnQ yllq11xEoelJbWjqlS7RbfUViOVbrxJbV+8j AYnLEC3/YGdoDUeVBPk2hqfGB8vMZfsu/d1Y bhcMej6fIoXj/q4HIXNSD9UcP0CNtLR6n7Bq ndtF5V/pM6xI0tiE51KudVttsJI= ) 3600 NSEC example. A HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 1 2 3600 20031029215736 ( 20030929215736 4638 example. fi2La99VLlZhIPUgGd/Fd6MH8wJZ6ziSPW34 k214lDIQQBlu0X4V0z4DcZ/PDBeqvKOORmEI AhZLwELtWv5XSAmALYUr3Rrtp/H066R4EpAu Arends, et al. Expires March 30, 2004 [Page 44] Internet-Draft DNSSEC Protocol Modifications September 2003 YrS4pZ8/QFM+HnPUcofSK3IzLBucXsnDSYr0 fQ5nfoBQ++eHo+IEohbqrwnE60E= ) 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 March 30, 2004 [Page 45] Internet-Draft DNSSEC Protocol Modifications September 2003 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 (2003). 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 March 30, 2004 [Page 46] Internet-Draft DNSSEC Protocol Modifications September 2003 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 March 30, 2004 [Page 47]