diff options
Diffstat (limited to 'doc/rfc/rfc4035.txt')
| -rw-r--r-- | doc/rfc/rfc4035.txt | 2971 |
1 files changed, 2971 insertions, 0 deletions
diff --git a/doc/rfc/rfc4035.txt b/doc/rfc/rfc4035.txt new file mode 100644 index 0000000..b701cd2 --- /dev/null +++ b/doc/rfc/rfc4035.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4035 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + Protocol Modifications for the DNS Security Extensions + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is part of a family of documents that describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications that + 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 by 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. + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . . 4 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9 + 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 . . . . . . . . . . . . . . . . 19 + 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 . . . . . . . . . . . . . . . . 21 + 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 . . . . . . . . . . . . . 24 + 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24 + 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 with an RRSIG RR . . . . . . . . 28 + 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28 + 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29 + 5.3.3. Checking the Signature . . . . . . . . . . . . . 31 + 5.3.4. Authenticating a Wildcard Expanded RRset + Positive Response. . . . . . . . . . . . . . . . 32 + + + +Arends, et al. Standards Track [Page 2] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32 + 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33 + 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 9.2. Informative References . . . . . . . . . . . . . . . . . 35 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41 + B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41 + B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43 + B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44 + B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44 + B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45 + B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46 + B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47 + B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49 + C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49 + C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49 + C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50 + C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50 + C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50 + C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51 + C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51 + C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51 + C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications that 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 for handling signed zones. Section 4 + describes the behavior of entities that include security-aware + resolver functions. Finally, Section 5 defines how to use DNSSEC RRs + to authenticate a response. + + + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +1.1. Background and Related Documents + + This document is part of a family of documents defining DNSSEC that + should be read together as a set. + + [RFC4033] contains an introduction to DNSSEC and definitions of + common terms; the reader is assumed to be familiar with this + document. [RFC4033] also contains a list of other documents updated + by and obsoleted by this document set. + + [RFC4034] defines the DNSSEC resource records. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them; particularly, [RFC2181] and [RFC2308]. + + This document defines the DNSSEC protocol operations. + +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 [RFC2119]. + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), + Next Secure (NSEC), and (optionally) Delegation Signer (DS) records + according to the rules specified in Sections 2.1, 2.2, 2.3, and 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 does 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. + + + + + + + + + +Arends, et al. Standards Track [Page 4] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +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 [RFC4034]). 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 + [RFC4034]). + +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 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 not + counting the leftmost label if it is a wildcard. + + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset. + + 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 [RFC4034]. An RRset MAY have multiple RRSIG RRs + associated with it. Note that as RRSIG RRs are closely tied to the + RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS + + + +Arends, et al. Standards Track [Page 5] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RR types, do not form RRsets. In particular, the TTL values among + RRSIG RRs with a common owner name do not follow the RRset rules + described in [RFC2181]. + + An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would + add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated + with delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset + itself MUST be signed by each algorithm appearing in the DS RRset + located at the delegating parent (if any). + +2.3. Including NSEC RRs in a Zone + + Each owner name in the zone that has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + format of NSEC RRs and the process for constructing the NSEC RR for a + given name is described in [RFC4034]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not + the owner name of any RRset before the zone was signed. The main + reasons for this are a desire for namespace consistency between + signed and unsigned versions of the same zone and a desire to reduce + the risk of response inconsistency in security oblivious recursive + name servers. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + The difference between the set of owner names that require RRSIG + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + + + +Arends, et al. Standards Track [Page 6] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 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 + visible only during the zone signing process, as NSEC RRsets are + authoritative data and are therefore signed. Thus, any owner name + that has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + +2.4. Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR that is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. DS RRs that fail to meet these + conditions are not useful for validation, but because the DS RR and + its corresponding DNSKEY RR are in different zones, and because the + DNS is only loosely consistent, temporary mismatches can occur. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (that is, the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5. Changes to the CNAME Resource Record + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed ([RFC3007]). + Other types MUST NOT be present at that name. + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + + + +Arends, et al. Standards Track [Page 7] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + +2.6. DNSSEC RR Types Appearing at Zone Cuts + + DNSSEC introduced two new RR types that are unusual in that they can + appear at the parental side of a zone cut. At the parental side of a + zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at + the owner name. A DS RR could also be present if the zone being + delegated is signed and seeks to have a chain of authentication to + the parent zone. This is an exception to the original DNS + specification ([RFC1034]), which states that only NS RRsets could + appear at the parental side of a zone cut. + + This specification updates the original DNS specification to allow + NSEC and DS RR types at the parent side of a zone cut. These RRsets + are authoritative for the parent when they appear at the parent side + of a zone cut. + +2.7. Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + +3. Serving + + This section describes the behavior of entities that include + security-aware name server functions. In many cases such functions + will be part of a security-aware recursive name server, but a + security-aware authoritative name server has some of the same + requirements. Functions specific to security-aware recursive name + servers are described in Section 3.2; functions specific to + authoritative servers are described in Section 3.1. + + In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" + are as used in [RFC1034]. + + A security-aware name server MUST support the EDNS0 ([RFC2671]) + message size extension, MUST support a message size of at least 1220 + octets, and SHOULD support a message size of 4000 octets. As IPv6 + packets can only be fragmented by the source host, a security aware + name server SHOULD take steps to ensure that UDP datagrams it + transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 + MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], + and [RFC3226] for further discussion of packet size and fragmentation + issues. + + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware name server that receives a DNS query that does not + include the EDNS OPT pseudo-RR or that has the DO bit clear MUST + treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and + MUST NOT perform any of the additional processing described below. + Because the DS RR type has the peculiar property of only existing in + the parent zone at delegation points, DS RRs always require some + special processing, as described in Section 3.1.4.1. + + Security aware name servers that receive explicit queries for + security RR types that match the content of more than one zone that + it serves (for example, NSEC and RRSIG RRs above and below a + delegation point where the server is authoritative for both zones) + should behave self-consistently. As long as the response is always + consistent for each query to the name server, the name server MAY + return one of the following: + + o The above-delegation RRsets. + o The below-delegation RRsets. + o Both above and below-delegation RRsets. + o Empty answer section (no records). + o Some other response. + o An error. + + DNSSEC allocates two new bits in the DNS message header: the CD + (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + is controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Sections 3.1.6, + 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. + + A security aware name server that synthesizes CNAME RRs from DNAME + RRs as described in [RFC2672] SHOULD NOT generate signatures for the + synthesized CNAME RRs. + +3.1. Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT + pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name + server for a signed zone MUST include additional RRSIG, NSEC, and DS + RRs, according to the following rules: + + o RRSIG RRs that can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1. + + + + + + + +Arends, et al. Standards Track [Page 9] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + o NSEC RRs that can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.1.3. + + o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST + be included in referrals automatically according to the rules in + Section 3.1.4. + + These rules only apply to responses where the semantics convey + information about the presence or absence of resource records. That + is, these rules are not intended to rule out responses such as RCODE + 4 ("Not Implemented") or RCODE 5 ("Refused"). + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1. Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server SHOULD attempt to send RRSIG RRs that a + security-aware resolver can use to authenticate the RRsets in the + response. A name server SHOULD make every attempt to keep the RRset + and its associated RRSIG(s) together in a response. Inclusion of + RRSIG RRs in a response is subject to the following rules: + + o When placing a signed RRset in the Answer section, the name server + MUST also place its RRSIG RRs in the Answer section. The RRSIG + RRs have a higher priority for inclusion than any other RRsets + that may have 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 have to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Additional section, the name + server MUST also place its RRSIG RRs in the Additional section. + If space does not permit inclusion of both the RRset and its + associated RRSIG RRs, the name server MAY retain the RRset while + dropping the RRSIG RRs. If this happens, the name server MUST NOT + set the TC bit solely because these RRSIG RRs didn't fit. + + + + + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.2. Including DNSKEY RRs in a Response + + When responding to a query that has the DO bit set and that requests + the SOA or NS RRs at the apex of a signed zone, a security-aware + authoritative name server for that zone MAY return the zone apex + DNSKEY RRset in the Additional section. In this situation, the + DNSKEY RRset and associated RRSIG RRs have lower priority than does + any other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + +3.1.3. Including NSEC RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server for a signed zone MUST include NSEC RRs in + each of the following cases: + + No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> + but does not contain any RRsets that exactly match <SNAME, SCLASS, + STYPE>. + + Name Error: The zone does not contain any RRsets that match <SNAME, + SCLASS> either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match <SNAME, SCLASS> but does contain an RRset that matches + <SNAME, SCLASS, STYPE> via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match <SNAME, SCLASS> and does contain one or more RRsets that + match <SNAME, SCLASS> via wildcard name expansion, but does not + contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard + name expansion. + + In each of these cases, the name server includes NSEC RRs in the + response to prove that an exact match for <SNAME, SCLASS, STYPE> was + not present in the zone and that the response that the name server is + returning is correct given the data in the zone. + + + + + + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.3.1. Including NSEC RRs: No Data Response + + If the zone contains RRsets matching <SNAME, SCLASS> but contains no + RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST + include the NSEC RR for <SNAME, SCLASS> along with its associated + RRSIG RR(s) in the Authority section of the response (see Section + 3.1.1). If space does not permit inclusion of the NSEC RR or its + associated RRSIG RR(s), the name server MUST set the TC bit (see + Section 3.1.1). + + Since the search name exists, wildcard name expansion does not apply + to this query, and a single signed NSEC RR suffices to prove that the + requested RR type does not exist. + +3.1.3.2. Including NSEC RRs: Name Error Response + + If the zone does not contain any RRsets matching <SNAME, SCLASS> + either exactly or via wildcard name expansion, then the name server + MUST include the following NSEC RRs in the Authority section, along + with their associated RRSIG RRs: + + o An NSEC RR proving that there is no exact match for <SNAME, + SCLASS>. + + o An NSEC RR proving that the zone contains no RRsets that would + match <SNAME, SCLASS> via wildcard name expansion. + + In some cases, a single NSEC RR may prove both of these points. If + it does, the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + Note that this form of response includes cases in which SNAME + corresponds to an empty non-terminal name within the zone (a name + that is not the owner name for any RRset but that is the parent name + of one or more RRsets). + +3.1.3.3. Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets that exactly match <SNAME, + SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> + via wildcard name expansion, the name server MUST include the + + + +Arends, et al. Standards Track [Page 12] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + wildcard-expanded answer and the corresponding wildcard-expanded + RRSIG RRs in the Answer section and MUST include in the Authority + section an NSEC RR and associated RRSIG RR(s) proving that the zone + does not contain a closer match for <SNAME, SCLASS>. If space does + not permit inclusion of the answer, NSEC and RRSIG RRs, the name + server MUST set the TC bit (see Section 3.1.1). + +3.1.3.4. Including NSEC RRs: Wildcard No Data Response + + This case is a combination of the previous cases. The zone does not + contain an exact match for <SNAME, SCLASS>, and although the zone + does contain RRsets that match <SNAME, SCLASS> via wildcard + expansion, none of those RRsets matches STYPE. The name server MUST + include the following NSEC RRs in the Authority section, along with + their associated RRSIG RRs: + + o An NSEC RR proving that there are no RRsets matching STYPE at the + wildcard owner name that matched <SNAME, SCLASS> via wildcard + expansion. + + o An NSEC RR proving that there are no RRsets in the zone that would + have been a closer match for <SNAME, SCLASS>. + + In some cases, a single NSEC RR may prove both of these points. If + it does, the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5. Finding the Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server has to locate an NSEC RR + that proves that no RRsets matching a particular SNAME exist. + Locating such an NSEC RR within an authoritative zone is relatively + simple, at least in concept. The following discussion assumes that + the name server is authoritative for the zone that would have held + the non-existent RRsets matching SNAME. The algorithm below is + written for clarity, not for efficiency. + + To find the NSEC that proves that no RRsets matching name N exist in + the zone Z that would have held them, construct a sequence, S, + consisting of the owner names of every RRset in Z, sorted into + + + +Arends, et al. Standards Track [Page 13] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + canonical order ([RFC4034]), with no duplicate names. Find the name + M that would have immediately preceded N in S if any RRsets with + owner name N had existed. M is the owner name of the NSEC RR that + proves that no RRsets exist with owner name N. + + The algorithm for finding the NSEC RR that proves that a given name + is not covered by any applicable wildcard is similar but requires an + extra step. More precisely, the algorithm for finding the NSEC + proving that no RRsets exist with the applicable wildcard name is + precisely the same as the algorithm for finding the NSEC RR that + proves that RRsets with any other owner name do not exist. The part + that's missing is a method of determining the name of the non- + existent applicable wildcard. In practice, this is easy, because the + authoritative name server has already checked for the presence of + precisely this wildcard name as part of step (1)(c) of the normal + lookup algorithm described in Section 4.3.2 of [RFC1034]. + +3.1.4. Including DS RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server returning a referral includes DNSSEC data + along with the NS RRset. + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR that proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1. Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, as the name server for the + child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + + +Arends, et al. Standards Track [Page 14] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + + o The name server has received a query for the DS RRset at a zone + cut. + + o The name server is authoritative for the child zone. + + o The name server is not authoritative for the parent zone. + + o The name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5. Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation. + + 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 to meet 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 that + + + +Arends, et al. Standards Track [Page 15] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + chooses to perform its own zone validation MUST NOT selectively + reject some RRs and accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + of the zone in which the RRset is authoritative data. In the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut and + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, as the NSEC RR in the child zone's apex will always indicate + the presence of the child zone's SOA RR whereas the parental NSEC RR + at the zone cut will never indicate the presence of an SOA RR. As + with any other authoritative RRs, NSEC RRs MUST be included in zone + transfers of the zone in which they are authoritative data. The + parental NSEC RR at a zone cut MUST be included in zone transfers of + the parent zone, and the NSEC at the zone apex of the child zone MUST + be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut and + are authoritative in whichever zone contains the authoritative RRset + for which the RRSIG RR provides the signature. That is, the RRSIG RR + for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, and the RRSIG for any RRset in the + child zone's apex will be authoritative in the child zone. Parental + and child RRSIG RRs at a zone cut will never be identical to each + other, as the Signer's Name field of an RRSIG RR in the child zone's + apex will indicate a DNSKEY RR in the child zone's apex whereas the + same field of a parental RRSIG RR at the zone cut will indicate a + DNSKEY RR in the parent zone's apex. As with any other authoritative + RRs, RRSIG RRs MUST be included in zone transfers of the zone in + which they are authoritative data. + +3.1.6. The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed for use in communication between + security-aware resolvers and security-aware recursive name servers. + These bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + A security-aware name server does not perform signature validation + for authoritative data during query processing, even when the CD bit + is clear. A security-aware name server SHOULD clear the CD bit when + composing an authoritative response. + + + + + +Arends, et al. Standards Track [Page 16] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation. However, the name + server MUST NOT do so unless the name server obtained the + authoritative zone via secure means (such as a secure zone transfer + mechanism) and MUST NOT do so unless this behavior has been + configured explicitly. + + A security-aware name server that supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2. Recursive Name Servers + + As explained in [RFC4033], a security-aware recursive name server is + an entity that 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 that implements the + security-aware name server role and the code that implements the + security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching that would apply to any security-aware resolver. + +3.2.1. The DO Bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response but MUST + NOT strip any DNSSEC RR types that the initiating query explicitly + requested. + +3.2.2. The CD Bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + The name server side of a security-aware recursive name server MUST + pass the state of the CD bit to the resolver side along with the rest + + + +Arends, et al. Standards Track [Page 17] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + of an initiating query, so that the resolver side will know whether + it is required to verify the response data it returns to the name + server side. If the CD bit is set, it indicates that the originating + resolver is willing to perform whatever authentication its local + policy requires. Thus, the resolver side of the recursive name + server need not perform authentication on the RRsets in the response. + When the CD bit is set, the recursive name server SHOULD, if + possible, return the requested data to the originating resolver, even + if the recursive name server's local authentication policy would + reject the records in question. That is, by setting the CD bit, the + originating resolver has indicated that it takes responsibility for + performing its own authentication, and the recursive name server + should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query that matches an entry in the + resolver side's BAD cache, the name server side's response depends on + the state of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + + The intent of the above rule is to provide the raw data to clients + that are capable of performing their own signature verification + checks while protecting clients that depend on the resolver side of a + security-aware recursive name server to perform such checks. Several + of the possible reasons why signature validation might fail involve + conditions that may not apply equally to the recursive name server + and the client that invoked it. For example, the recursive name + server's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security that the recursive name + server does not share. In such cases, "protecting" a client that is + capable of performing its own signature validation from ever seeing + the "bad" data does not help the client. + +3.2.3. The AD Bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + authentic. The name server side SHOULD set the AD bit if and only if + the resolver side considers all RRsets in the Answer section and any + relevant negative response RRs in the Authority section to be + authentic. The resolver side MUST follow the procedure described in + Section 5 to determine whether the RRs in question are authentic. + However, for backward compatibility, a recursive name server MAY set + the AD bit when a response includes unsigned CNAME RRs if those CNAME + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RRs demonstrably could have been synthesized from an authentic DNAME + RR that is also included in the response according to the synthesis + rules described in [RFC2672]. + +3.3. Example DNSSEC Responses + + See Appendix B for example response packets. + +4. Resolving + + This section describes the behavior of entities that include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1. EDNS Support + + A security-aware resolver MUST include an EDNS ([RFC2671]) OPT + pseudo-RR with the DO ([RFC3225]) bit set 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 + use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR + to advertise the message size that it is willing to accept. A + security-aware resolver's IP layer MUST handle fragmented UDP packets + correctly regardless of whether any such fragmented packets were + received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and + [RFC3226] for discussion of these requirements. + +4.2. Signature Verification Support + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5 and SHOULD 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 that instructed the security-aware + resolver not to perform validation for this query; or + + o validation for this query has been disabled by local policy. + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + Security-aware resolvers MAY query for missing security RRs in an + attempt to perform validation; implementations that choose to do so + must be aware that the answers received may not be sufficient to + validate the original response. For example, a zone update may have + changed (or deleted) the desired information between the original and + follow-up queries. + + When attempting to retrieve missing NSEC RRs that reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name. If no NS RRset is present at that name, the + resolver then strips off the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + +4.3. Determining Security Status of Data + + A security-aware resolver MUST be able to determine whether it should + expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between four + cases: + + Secure: An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted security anchor to the + RRset. In this case, the RRset should be signed and is subject to + signature validation, as described above. + + Insecure: 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. + + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + Bogus: An RRset for which the resolver believes that it ought to be + able to establish a chain of trust but for which it is unable to + do so, either due to signatures that for some reason fail to + validate or due to missing data that the relevant DNSSEC RRs + indicate should be present. This case may indicate an attack but + may also indicate a configuration error or some form of data + corruption. + + Indeterminate: An RRset for which the resolver is not able to + determine whether the RRset should be signed, as the resolver is + not able to obtain the necessary DNSSEC RRs. This can occur when + the security-aware resolver is not able to contact security-aware + name servers for the relevant zones. + +4.4. Configured Trust Anchors + + A security-aware resolver MUST be capable of being configured with at + least one trusted public key or DS RR and SHOULD be capable of being + configured with multiple trusted public keys or DS RRs. Since a + security-aware resolver will not be able to validate signatures + without such a configured trust anchor, the resolver SHOULD have some + reasonably robust mechanism for obtaining such keys when it boots; + examples of such a mechanism would be some form of non-volatile + storage (such as a disk drive) or some form of trusted local network + configuration mechanism. + + Note that trust anchors also cover key material that is updated in a + secure manner. This secure manner could be through physical media, a + key exchange protocol, or some other out-of-band means. + +4.5. Response Caching + + A security-aware resolver SHOULD cache each response as a single + atomic entry containing the entire answer, including the named RRset + and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. In + most cases the appropriate cache index for the atomic entry will be + the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double <QNAME,QCLASS>. + + The reason for these recommendations is that, between the initial + query and the expiration of the data from the cache, the + authoritative data might have been changed (for example, via dynamic + update). + + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + There are two situations for which this is relevant: + + 1. By using the RRSIG record, it is possible to deduce that an + answer was synthesized from a wildcard. A security-aware + recursive name server could store this wildcard data and use it + to generate positive responses to queries other than the name for + which the original answer was first received. + + 2. NSEC RRs received to prove the non-existence of a name could be + reused by a security-aware resolver to prove the non-existence of + any name in the name range it spans. + + In theory, a resolver could use wildcards or NSEC RRs to generate + positive and negative responses (respectively) until the TTL or + signatures on the records in question expire. However, it seems + prudent for resolvers to avoid blocking new authoritative data or + synthesizing new data on their own. Resolvers that follow this + recommendation will have a more consistent view of the namespace. + +4.6. Handling of the CD and AD Bits + + A security-aware resolver MAY set a query's CD bit in order to + indicate that the resolver takes responsibility for performing + whatever authentication its local policy requires on the RRsets in + the response. See Section 3.2 for the effect this bit has on the + behavior of security-aware recursive name servers. + + A security-aware resolver MUST clear the AD bit when composing query + messages to protect against buggy name servers that blindly copy + header bits that they do not understand from the query message to the + response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained by using a secure channel + or the resolver was specifically configured to regard the message + header bits without using a secure channel. + +4.7. Caching BAD Data + + While many validation errors will be transient, some are likely to be + more persistent, such as those caused by administrative error + (failure to re-sign a zone, clock skew, and so forth). Since + requerying will not help in these cases, validating resolvers might + generate a significant amount of unnecessary DNS traffic as a result + of repeated queries for RRsets with persistent validation failures. + + To prevent such unnecessary DNS traffic, security-aware resolvers MAY + cache data with invalid signatures, with some restrictions. + + + +Arends, et al. Standards Track [Page 22] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + Conceptually, caching such data is similar to negative caching + ([RFC2308]), except that instead of caching a valid negative + response, the resolver is caching the fact that a particular answer + failed to validate. This document refers to a cache of data with + invalid signatures as a "BAD cache". + + Resolvers that implement a BAD cache MUST take steps to prevent the + cache from being useful as a denial-of-service attack amplifier, + particularly the following: + + o Since RRsets that fail to validate do not have trustworthy TTLs, + the implementation MUST assign a TTL. This TTL SHOULD be small, + in order to mitigate the effect of caching the results of an + attack. + + o In order to prevent caching of a transient validation failure + (which might be the result of an attack), resolvers SHOULD track + queries that result in validation failures and SHOULD only answer + from the BAD cache after the number of times that responses to + queries for that particular <QNAME, QTYPE, QCLASS> have failed to + validate exceeds a threshold value. + + Resolvers MUST NOT return RRsets from the BAD cache unless the + resolver is not required to validate the signatures of the RRsets in + question under the rules given in Section 4.2 of this document. See + Section 3.2.2 for discussion of how the responses returned by a + security-aware recursive name server interact with a BAD cache. + +4.8. Synthesized CNAMEs + + A validating security-aware resolver MUST treat the signature of a + valid signed DNAME RR as also covering unsigned CNAME RRs that could + have been synthesized from the DNAME RR, as described in [RFC2672], + at least to the extent of not rejecting a response message solely + because it contains such CNAME RRs. The resolver MAY retain such + CNAME RRs in its cache or in the answers it hands back, but is not + required to do so. + +4.9. Stub Resolvers + + A security-aware stub resolver MUST support the DNSSEC RR types, at + least to the extent of not mishandling responses just because they + contain DNSSEC RRs. + + + + + + + + +Arends, et al. Standards Track [Page 23] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +4.9.1. Handling of the DO Bit + + A non-validating security-aware stub resolver MAY include the DNSSEC + RRs returned by a security-aware recursive name server as part of the + data that the stub resolver hands back to the application that + invoked it, but is not required to do so. A non-validating stub + resolver that seeks to do this will need to set the DO bit in order + to receive DNSSEC RRs from the recursive name server. + + A validating security-aware stub resolver MUST set the DO bit, + because otherwise it will not receive the DNSSEC RRs it needs to + perform signature validation. + +4.9.2. Handling of the CD Bit + + A non-validating security-aware stub resolver SHOULD NOT set the CD + bit when sending queries unless it is requested by the application + layer, as by definition, a non-validating stub resolver depends on + the security-aware recursive name server to perform validation on its + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + because otherwise the security-aware recursive name server will + answer the query using the name server's local policy, which may + prevent the stub resolver from receiving data that would be + acceptable to the stub resolver's local policy. + +4.9.3. Handling of the AD Bit + + A non-validating security-aware stub resolver MAY chose to examine + the setting of the AD bit in response messages that it receives in + order to determine whether the security-aware recursive name server + that 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. Therefore, there may be little + practical value in checking the status of the AD bit, except perhaps + as a debugging aid. In any case, a security-aware stub resolver MUST + NOT place any reliance on signature validation allegedly performed on + its behalf, except when the security-aware stub resolver obtained the + data in question from a trusted security-aware recursive name server + via a secure channel. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, as, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + +Arends, et al. Standards Track [Page 24] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5. Authenticating DNS Responses + + To use DNSSEC RRs for authentication, a security-aware resolver + requires configured knowledge of at least one authenticated DNSKEY or + DS RR. The process for obtaining and authenticating this initial + trust anchor 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 to 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 + trust anchors. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset by using an initial key, + the resolver MUST: + + 1. verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA + bit 7) set; and + + 2. verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset by using an + initial DNSKEY RR, delegations from that zone can be authenticated by + 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 configured 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. + + 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 once the resolver has authenticated a zone's apex + DNSKEY RRset. Section 5.4 shows how the resolver can use + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + lacks the appropriate DNSSEC RRs, whether due to configuration issues + such as an upstream security-oblivious recursive name server that + + + +Arends, et al. Standards Track [Page 25] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + accidentally interferes 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 [RFC4033]) 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 that the validator have some other means of obtaining an + initial authenticated zone key for the island. If a validator cannot + obtain such a key, it SHOULD switch to operating as if the zones in + the island of security are unsigned. + + 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 trust anchor 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. Use of a strong cryptographic digest + algorithm ensures that it is computationally infeasible for an + adversary to 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). + + + + + +Arends, et al. Standards Track [Page 26] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 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 + RRset, and, when the DNSKEY RR's owner name and RDATA are hashed + using the digest algorithm specified in the DS RR's Digest Type + field, the resulting digest value matches the Digest field of the + DS RR. + + o The matching DNSKEY RR in the child zone has the Zone Flag bit + set, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the validator authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the validator cannot authenticate RRsets in or below the + child zone. + + If the validator does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + 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 because 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. + + + + + + +Arends, et al. Standards Track [Page 27] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3. Authenticating an RRset with an RRSIG RR + + A validator can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The validator first checks the RRSIG + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The validator 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, the validator uses the public key and + signature to authenticate the signed data. Sections 5.3.1, 5.3.2, + and 5.3.3 describe each step in detail. + +5.3.1. Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + + o The RRSIG RR and the RRset MUST have the same owner name and the + same class. + + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset. + + o The RRSIG RR's Type Covered field MUST equal the RRset's type. + + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field. + + o The validator'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 validator'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. + + + + + +Arends, et al. Standards Track [Page 28] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the validator cannot predetermine which DNSKEY + RR to use to authenticate the signature, and it MUST try each + matching DNSKEY RR until either the signature is validated or the + validator has run out of matching public keys to try. + + Note that this authentication process is only meaningful if the + validator 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 trust anchor. + +5.3.2. Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + Section 5.3.1, the validator has 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 validator 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 | type | class | 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 + + + + +Arends, et al. Standards Track [Page 29] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + RRset. + + The canonical forms for names and RRsets are defined in [RFC4034]. + + 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 + RRsets 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 as only a child NSEC RR will indicate that 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. 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 that each of the two NSEC RRsets at a delegation point has a + corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + + + + + + + + +Arends, et al. Standards Track [Page 30] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +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 validator can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] + provides a list of algorithm types and provides pointers to the + documents that define each algorithm's use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the validator can only + determine which DNSKEY RR is correct by trying each matching public + key until the validator either succeeds in validating the signature + or runs out of keys to try. + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also has to test these RRSIG + RRs and how to resolve conflicts if these RRSIG RRs lead to differing + results. + + If the resolver accepts the RRset as authentic, the validator 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; + + o the value in the RRSIG RR's Original TTL field; and + + o the difference of the RRSIG RR's Signature Expiration time and the + current time. + + + + + +Arends, et al. Standards Track [Page 31] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5.3.4. Authenticating a Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the validator has verified the signature, as described in + Section 5.3, it must take additional steps to verify the non- + existence of an exact match or closer wildcard match for the query. + Section 5.4 discusses these steps. + + Note that the response received by the resolver should include all + NSEC RRs needed to authenticate the response (see Section 3.1.3). + +5.4. Authenticated Denial of Existence + + 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. + + Denial of existence is determined by the following rules: + + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. + + o If the requested RR name would appear after an authenticated NSEC + RR's owner name and before the name listed in that NSEC RR's Next + Domain Name field according to the canonical DNS name order + defined in [RFC4034], then no RRsets with the requested name exist + in the zone. However, it is possible that a wildcard could be + used to match the requested RR owner name and type, so proving + that the requested RRset does not exist also requires proving that + no possible wildcard RRset exists that could have been used to + generate a positive response. + + In addition, security-aware resolvers MUST authenticate the NSEC + RRsets that comprise the non-existence proof as described in Section + 5.3. + + To prove the 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 + + + +Arends, et al. Standards Track [Page 32] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify the 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 validated NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a validator MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + +5.5. Resolver Behavior When Signatures Do Not Validate + + If for whatever reason none of the RRSIGs can be validated, the + response SHOULD be considered BAD. If the validation was being done + to service a recursive query, the name server MUST return RCODE 2 to + the originating client. However, it MUST return the full response if + and only if the original query had the CD bit set. Also see Section + 4.7 on caching responses that do not validate. + +5.6. Authentication Example + + Appendix C shows an example of the authentication process. + +6. IANA Considerations + + [RFC4034] contains a review of the IANA considerations introduced by + DNSSEC. The following are additional IANA considerations discussed + in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655], and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [RFC4033] for terminology and general security + considerations related to DNSSEC; see [RFC4034] for considerations + specific to the DNSSEC resource record types. + + + + +Arends, et al. Standards Track [Page 33] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection that DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Sections 3.2.2 and 4.9 for further discussion. + + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, as + recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will have to pay close attention to the + behavior of the applications that use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidentally denying service to the clients it + is intended to support. + +8. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. + +9. References + +9.1. 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. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [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. + + + + +Arends, et al. Standards Track [Page 34] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, 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. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for DNS Security Extensions", RFC + 4034, March 2005. + +9.2. Informative References + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 35] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB + 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE + VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO + 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM + W6OISukd1EQt7a0kygkg+PEDxdI= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + 3600 DNSKEY 256 3 5 ( + AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV + rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e + k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo + vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI + + + +Arends, et al. Standards Track [Page 36] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== + ) + 3600 DNSKEY 257 3 5 ( + AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl + LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ + syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP + RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT + Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 9465 example. + ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ + xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ + XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 + hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY + NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z + DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri + bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp + eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk + 7z5OXogYVaFzHKillDt3HRxHIZM= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba + U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 + 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I + BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g + sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + + + +Arends, et al. Standards Track [Page 37] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l + e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh + ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 + AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw + FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG + CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p + P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN + 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL + AhS+JOVfDI/79QtyTI0SaDWcg8U= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + + + +Arends, et al. Standards Track [Page 38] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE + VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb + 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH + l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw + Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + + + +Arends, et al. Standards Track [Page 39] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK + vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E + mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI + NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e + IjgiM8PXkBQtxPq37wDKALkyn7Q= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia + t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj + q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq + GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb + +gLcMZBnHJ326nb/TOOmrqNmQQE= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 + t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq + BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 + 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ + RgNvuwbioFSEuv2pNlkq0goYxNY= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + + + +Arends, et al. Standards Track [Page 40] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY + 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k + mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi + asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W + GghLahumFIpg4MO3LS/prgzVVWo= ) + + 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 that 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. + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1. Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + + + +Arends, et al. Standards Track [Page 41] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + + + + +Arends, et al. Standards Track [Page 42] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.2. Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + + + +Arends, et al. Standards Track [Page 43] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.3. No Data Error + + A "no data" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + + ;; Additional + ;; (empty) + +B.4. Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + ;; Header: QR DO RCODE=0 + ;; + + + +Arends, et al. Standards Track [Page 44] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + +B.5. Referral to Unsigned Zone + + Referral to an unsigned zone. The NSEC RR proves that no DS RR for + this delegation exists in the parent zone. + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + + +Arends, et al. Standards Track [Page 45] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + +B.6. Wildcard Expansion + + A successful query that was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + + + +Arends, et al. Standards Track [Page 46] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 20040409183619 38519 example. + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + +B.7. Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + + + +Arends, et al. Standards Track [Page 47] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + + ;; Additional + ;; (empty) + +B.8. DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + + + +Arends, et al. Standards Track [Page 48] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1. Authenticating an Answer + + The query in Appendix B.1 returned an MX RRset for "x.w.example.com". + The corresponding RRSIG indicates that the MX RRset was signed by an + "example" DNSKEY with algorithm 5 and key tag 38519. The resolver + needs the corresponding DNSKEY RR in order to authenticate this + answer. The discussion below describes how a resolver might obtain + this DNSKEY RR. + + The RRSIG indicates the original TTL of the MX RRset was 3600, and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates that the answer + was not the result of wildcard expansion. The "x.w.example.com" MX + RRset is placed in canonical form, and, assuming the current time + falls between the signature inception and expiration dates, the + signature is authenticated. + +C.1.1. Authenticating the Example DNSKEY RR + + This example shows the logical authentication process that starts + from the a configured root DNSKEY (or DS RR) and moves down the tree + to authenticate the desired "example" DNSKEY RR. Note that the + logical order is presented for clarity. An implementation may choose + to construct the authentication as referrals are received or to + construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with a configured DNSKEY RR for the + root zone (or a configured DS RR for the root zone). The resolver + checks whether this configured DNSKEY RR is present in the root + DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root + DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY + RRset, and whether the signature lifetime is valid. If all these + + + +Arends, et al. Standards Track [Page 49] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + conditions are met, all keys in the DNSKEY RRset are considered + authenticated. The resolver then uses one (or more) of the root + DNSKEY RRs to authenticate the "example" DS RRset. Note that the + resolver may have to query the root zone to obtain the root DNSKEY + RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + matching "example" DNSKEY is found, the resolver checks whether this + DNSKEY RR has signed the "example" DNSKEY RRset and the signature + lifetime is valid. If these conditions are met, all keys in the + "example" DNSKEY RRset are considered authenticated. + + Finally, the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This + DNSKEY is used to authenticate the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried, and the answer is authenticated if any + of the matching DNSKEY RRs validate the signature as described above. + +C.2. Name Error + + The query in Appendix B.2 returned NSEC RRs that prove that the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3. No Data Error + + The query in Appendix B.3 returned an NSEC RR that proves that the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4. Referral to Signed Zone + + The query in Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks whether + + + +Arends, et al. Standards Track [Page 50] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether + the signature lifetime is valid. If all these conditions are met, + all keys in the "a.example" DNSKEY RRset are considered + authenticated. + +C.5. Referral to Unsigned Zone + + The query in Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + "example" to "b.example", and the NSEC RR is authenticated in a + manner identical to that of the MX RRset discussed above. + +C.6. Wildcard Expansion + + The query in Appendix B.6 returned an answer that was produced as a + result of wildcard expansion. The answer section contains a wildcard + RRset expanded as it would be in a traditional DNS response, and the + corresponding RRSIG indicates that the expanded wildcard MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The RRSIG indicates that the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG labels field value of 2 indicates that the answer + is the result of wildcard expansion, as the "a.z.w.example" name + contains 4 labels. The name "a.z.w.w.example" is replaced by + "*.w.example", the MX RRset is placed in canonical form, and, + assuming that the current time falls between the signature inception + and expiration dates, the signature is authenticated. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query, and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7. Wildcard No Data Error + + The query in Appendix B.7 returned NSEC RRs that prove that the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8. DS Child Zone No Data Error + + The query in Appendix B.8 returned NSEC RRs that shows the requested + was answered by a child server ("example" server). The NSEC RR + indicates the presence of an SOA RR, showing that the answer is from + the child . Queries for the "example" DS RRset should be sent to the + parent servers ("root" servers). + + + + + + +Arends, et al. Standards Track [Page 51] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.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. Standards Track [Page 52] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 53] + |