idnits 2.17.1 draft-ietf-dnsext-dnssec-protocol-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2449. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC2535, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 10, 2004) is 7131 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1982' is defined on line 1570, but no explicit reference was found in the text == Unused Reference: 'RFC2930' is defined on line 1602, but no explicit reference was found in the text == Unused Reference: 'RFC2931' is defined on line 1605, but no explicit reference was found in the text == Unused Reference: 'RFC3658' is defined on line 1614, but no explicit reference was found in the text == Unused Reference: 'RFC3845' is defined on line 1617, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dnssec-intro-10 == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-08 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3655 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3845 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions R. Arends 3 Internet-Draft Telematica Instituut 4 Expires: April 10, 2005 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 October 10, 2004 14 Protocol Modifications for the DNS Security Extensions 15 draft-ietf-dnsext-dnssec-protocol-09 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 10, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). 48 Abstract 49 This document is part of a family of documents which describe the DNS 50 Security Extensions (DNSSEC). The DNS Security Extensions are a 51 collection of new resource records and protocol modifications which 52 add data origin authentication and data integrity to the DNS. This 53 document describes the DNSSEC protocol modifications. This document 54 defines the concept of a signed zone, along with the requirements for 55 serving and resolving using DNSSEC. These techniques allow a 56 security-aware resolver to authenticate both DNS resource records and 57 authoritative DNS error indications. 59 This document obsoletes RFC 2535 and incorporates changes from all 60 updates to RFC 2535. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1 Background and Related Documents . . . . . . . . . . . . . 4 66 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5 69 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 70 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 71 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 72 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8 73 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 74 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 75 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10 77 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 78 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 79 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 80 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 81 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 82 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 83 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 84 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 85 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 86 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 87 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19 88 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20 90 4.2 Signature Verification Support . . . . . . . . . . . . . . 20 91 4.3 Determining Security Status of Data . . . . . . . . . . . 21 92 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 22 93 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22 94 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 23 95 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 23 96 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 24 97 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 24 98 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24 99 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24 100 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 25 101 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 26 102 5.1 Special Considerations for Islands of Security . . . . . . 27 103 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 27 104 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 28 105 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 29 106 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 29 107 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 31 108 5.3.4 Authenticating A Wildcard Expanded RRset Positive 109 Response . . . . . . . . . . . . . . . . . . . . . . . 32 110 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 32 111 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 33 112 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 33 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 114 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 115 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 116 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 117 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 118 9.2 Informative References . . . . . . . . . . . . . . . . . . . 38 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38 120 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 40 121 B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 46 122 B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 46 123 B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 47 124 B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 48 125 B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 49 126 B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 50 127 B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 51 128 B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 52 129 B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 53 130 C. Authentication Examples . . . . . . . . . . . . . . . . . . . 55 131 C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 55 132 C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 55 133 C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 56 134 C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 56 135 C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 56 136 C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 56 137 C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 57 138 C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 57 139 C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 57 140 Intellectual Property and Copyright Statements . . . . . . . . 58 142 1. Introduction 144 The DNS Security Extensions (DNSSEC) are a collection of new resource 145 records and protocol modifications which add data origin 146 authentication and data integrity to the DNS. This document defines 147 the DNSSEC protocol modifications. Section 2 of this document 148 defines the concept of a signed zone and lists the requirements for 149 zone signing. Section 3 describes the modifications to authoritative 150 name server behavior necessary to handle signed zones. Section 4 151 describes the behavior of entities which include security-aware 152 resolver functions. Finally, Section 5 defines how to use DNSSEC RRs 153 to authenticate a response. 155 1.1 Background and Related Documents 157 This document is part of a family of documents that define DNSSEC, 158 which should be read together as a set. 160 [I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and 161 definitions of common terms; the reader is assumed to be familiar 162 with this document. [I-D.ietf-dnsext-dnssec-intro] also contains a 163 list of other documents updated by and obsoleted by this document 164 set. 166 [I-D.ietf-dnsext-dnssec-records] defines the DNSSEC resource records. 168 The reader is also assumed to be familiar with the basic DNS concepts 169 described in [RFC1034], [RFC1035], and the subsequent documents that 170 update them, particularly [RFC2181] and [RFC2308]. 172 This document defines the DNSSEC protocol operations. 174 1.2 Reserved Words 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119. [RFC2119]. 180 2. Zone Signing 182 DNSSEC introduces the concept of signed zones. A signed zone 183 includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), 184 Next Secure (NSEC) and (optionally) Delegation Signer (DS) records 185 according to the rules specified in Section 2.1, Section 2.2, Section 186 2.3 and Section 2.4, respectively. A zone that does not include 187 these records according to the rules in this section is an unsigned 188 zone. 190 DNSSEC requires a change to the definition of the CNAME resource 191 record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG 192 and NSEC RRs to appear at the same owner name as a CNAME RR. 194 DNSSEC specifies the placement of two new RR types, NSEC and DS, 195 which can be placed at the parental side of a zone cut (that is, at a 196 delegation point). This is an exception to the general prohibition 197 against putting data in the parent zone at a zone cut. Section 2.6 198 describes this change. 200 2.1 Including DNSKEY RRs in a Zone 202 To sign a zone, the zone's administrator generates one or more 203 public/private key pairs and uses the private key(s) to sign 204 authoritative RRsets in the zone. For each private key used to 205 create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR 206 containing the corresponding public key. A zone key DNSKEY RR MUST 207 have the Zone Key bit of the flags RDATA field set -- see Section 208 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys associated 209 with other DNS operations MAY be stored in DNSKEY RRs that are not 210 marked as zone keys but MUST NOT be used to verify RRSIGs. 212 If the zone administrator intends a signed zone to be usable other 213 than as an island of security, the zone apex MUST contain at least 214 one DNSKEY RR to act as a secure entry point into the zone. This 215 secure entry point could then be used as the target of a secure 216 delegation via a corresponding DS RR in the parent zone (see 217 [I-D.ietf-dnsext-dnssec-records]). 219 2.2 Including RRSIG RRs in a Zone 221 For each authoritative RRset in a signed zone, there MUST be at least 222 one RRSIG record that meets all of the following requirements: 223 o The RRSIG owner name is equal to the RRset owner name; 224 o The RRSIG class is equal to the RRset class; 225 o The RRSIG Type Covered field is equal to the RRset type; 226 o The RRSIG Original TTL field is equal to the TTL of the RRset; 227 o The RRSIG RR's TTL is equal to the TTL of the RRset; 228 o The RRSIG Labels field is equal to the number of labels in the 229 RRset owner name, not counting the null root label and not 230 counting the leftmost label if it is a wildcard; 231 o The RRSIG Signer's Name field is equal to the name of the zone 232 containing the RRset; and 233 o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a 234 zone key DNSKEY record at the zone apex. 236 The process for constructing the RRSIG RR for a given RRset is 237 described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have 238 multiple RRSIG RRs associated with it. Note that, because RRSIG RRs 239 are closely tied to the RRsets whose signatures they contain, RRSIG 240 RRs, unlike all other DNS RR types, do not form RRsets. In 241 particular, the TTL values among RRSIG RRs with a common owner name 242 do not follow the RRset rules described in [RFC2181]. 244 An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR 245 would add no value and would create an infinite loop in the signing 246 process. 248 The NS RRset that appears at the zone apex name MUST be signed, but 249 the NS RRsets that appear at delegation points (that is, the NS 250 RRsets in the parent zone that delegate the name to the child zone's 251 name servers) MUST NOT be signed. Glue address RRsets associated 252 with delegations MUST NOT be signed. 254 There MUST be an RRSIG for each RRset using at least one DNSKEY of 255 each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset 256 itself MUST be signed by each algorithm appearing in the DS RRset 257 located at the delegating parent (if any). 259 2.3 Including NSEC RRs in a Zone 261 Each owner name in the zone which has authoritative data or a 262 delegation point NS RRset MUST have an NSEC resource record. The 263 format of NSEC RRs and the process for constructing the NSEC RR for a 264 given name is described in [I-D.ietf-dnsext-dnssec-records]. 266 The TTL value for any NSEC RR SHOULD be the same as the minimum TTL 267 value field in the zone SOA RR. 269 An NSEC record (and its associated RRSIG RRset) MUST NOT be the only 270 RRset at any particular owner name. That is, the signing process 271 MUST NOT create NSEC or RRSIG RRs for owner names nodes which were 272 not the owner name of any RRset before the zone was signed. The main 273 reasons for this are a desire for namespace consistency between 274 signed and unsigned versions of the same zone and a desire to reduce 275 the risk of response inconsistency in security oblivious recursive 276 name servers. 278 The type bitmap of every NSEC resource record in a signed zone MUST 279 indicate the presence of both the NSEC record itself and its 280 corresponding RRSIG record. 282 The difference between the set of owner names that require RRSIG 283 records and the set of owner names that require NSEC records is 284 subtle and worth highlighting. RRSIG records are present at the 285 owner names of all authoritative RRsets. NSEC records are present at 286 the owner names of all names for which the signed zone is 287 authoritative and also at the owner names of delegations from the 288 signed zone to its children. Neither NSEC nor RRSIG records are 289 present (in the parent zone) at the owner names of glue address 290 RRsets. Note, however, that this distinction is for the most part is 291 only visible during the zone signing process, because NSEC RRsets are 292 authoritative data, and are therefore signed, thus any owner name 293 which has an NSEC RRset will have RRSIG RRs as well in the signed 294 zone. 296 The bitmap for the NSEC RR at a delegation point requires special 297 attention. Bits corresponding to the delegation NS RRset and any 298 RRsets for which the parent zone has authoritative data MUST be set; 299 bits corresponding to any non-NS RRset for which the parent is not 300 authoritative MUST be clear. 302 2.4 Including DS RRs in a Zone 304 The DS resource record establishes authentication chains between DNS 305 zones. A DS RRset SHOULD be present at a delegation point when the 306 child zone is signed. The DS RRset MAY contain multiple records, 307 each referencing a public key in the child zone used to verify the 308 RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS 309 RRsets MUST NOT appear at a zone's apex. 311 A DS RR SHOULD point to a DNSKEY RR which is present in the child's 312 apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed 313 by the corresponding private key. DS RRs which fail to meet these 314 conditions are not useful for validation, but since the DS RR and its 315 corresponding DNSKEY RR are in different zones, and since the DNS is 316 only loosely consistent, temporary mismatches can occur. 318 The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset 319 (that is, the NS RRset from the same zone containing the DS RRset). 321 Construction of a DS RR requires knowledge of the corresponding 322 DNSKEY RR in the child zone, which implies communication between the 323 child and parent zones. This communication is an operational matter 324 not covered by this document. 326 2.5 Changes to the CNAME Resource Record. 328 If a CNAME RRset is present at a name in a signed zone, appropriate 329 RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that 330 name for secure dynamic update purposes is also allowed ([RFC3007]). 331 Other types MUST NOT be present at that name. 333 This is a modification to the original CNAME definition given in 334 [RFC1034]. The original definition of the CNAME RR did not allow any 335 other types to coexist with a CNAME record, but a signed zone 336 requires NSEC and RRSIG RRs for every authoritative name. To resolve 337 this conflict, this specification modifies the definition of the 338 CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. 340 2.6 DNSSEC RR Types Appearing at Zone Cuts. 342 DNSSEC introduced two new RR types that are unusual in that they can 343 appear at the parental side of a zone cut. At the parental side of a 344 zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at 345 the owner name. A DS RR could also be present if the zone being 346 delegated is signed and wishes to have a chain of authentication to 347 the parent zone. This is an exception to the original DNS 348 specification ([RFC1034]) which states that only NS RRsets could 349 appear at the parental side of a zone cut. 351 This specification updates the original DNS specification to allow 352 NSEC and DS RR types at the parent side of a zone cut. These RRsets 353 are authoritative for the parent when they appear at the parent side 354 of a zone cut. 356 2.7 Example of a Secure Zone 358 Appendix A shows a complete example of a small signed zone. 360 3. Serving 362 This section describes the behavior of entities that include 363 security-aware name server functions. In many cases such functions 364 will be part of a security-aware recursive name server, but a 365 security-aware authoritative name server has some of the same 366 requirements. Functions specific to security-aware recursive name 367 servers are described in Section 3.2; functions specific to 368 authoritative servers are described in Section 3.1. 370 The terms "SNAME", "SCLASS", and "STYPE" in the following discussion 371 are as used in [RFC1034]. 373 A security-aware name server MUST support the EDNS0 ([RFC2671]) 374 message size extension, MUST support a message size of at least 1220 375 octets, and SHOULD support a message size of 4000 octets. Since IPv6 376 packets can only be fragmented by the source host, a security aware 377 name server SHOULD take steps to ensure that UDP datagrams it 378 transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 379 MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], 380 and [RFC3226] for further discussion of packet size and fragmentation 381 issues. 383 A security-aware name server which receives a DNS query that does not 384 include the EDNS OPT pseudo-RR or that has the DO bit clear MUST 385 treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset, 386 and MUST NOT perform any of the additional processing described 387 below. Since the DS RR type has the peculiar property of only 388 existing in the parent zone at delegation points, DS RRs always 389 require some special processing, as described in Section 3.1.4.1. 391 Security aware name servers that receive explicit queries for 392 security RR types which match the content of more than one zone that 393 it serves (for example, NSEC and RRSIG RRs above and below a 394 delegation point where the server is authoritative for both zones) 395 should behave self-consistently. The name server MAY return one of 396 the following: 397 o The above-delegation RRsets 398 o The below-delegation RRsets 399 o Both above and below-delegation RRsets 400 o Empty answer section (no records) 401 o Some other response 402 o An error 403 As long as the response is always consistent for each query to the 404 name server. 406 DNSSEC allocates two new bits in the DNS message header: the CD 407 (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit 408 is controlled by resolvers; a security-aware name server MUST copy 409 the CD bit from a query into the corresponding response. The AD bit 410 is controlled by name servers; a security-aware name server MUST 411 ignore the setting of the AD bit in queries. See Section 3.1.6, 412 Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details 413 on the behavior of these bits. 415 A security aware name server which synthesizes CNAME RRs from DNAME 416 RRs as described in [RFC2672] SHOULD NOT generate signatures for the 417 synthesized CNAME RRs. 419 3.1 Authoritative Name Servers 421 Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT 422 pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name 423 server for a signed zone MUST include additional RRSIG, NSEC, and DS 424 RRs according to the following rules: 425 o RRSIG RRs that can be used to authenticate a response MUST be 426 included in the response according to the rules in Section 3.1.1; 427 o NSEC RRs that can be used to provide authenticated denial of 428 existence MUST be included in the response automatically according 429 to the rules in Section 3.1.3; 430 o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST 431 be included in referrals automatically according to the rules in 432 Section 3.1.4. 434 These rules only apply to responses the semantics of which convey 435 information about the presence or absence of resource records. That 436 is, these rules are not intended to rule out responses such as RCODE 437 4 ("Not Implemented") or RCODE 5 ("Refused"). 439 DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 440 discusses zone transfer requirements. 442 3.1.1 Including RRSIG RRs in a Response 444 When responding to a query that has the DO bit set, a security-aware 445 authoritative name server SHOULD attempt to send RRSIG RRs that a 446 security-aware resolver can use to authenticate the RRsets in the 447 response. A name server SHOULD make every attempt to keep the RRset 448 and its associated RRSIG(s) together in a response. Inclusion of 449 RRSIG RRs in a response is subject to the following rules: 450 o When placing a signed RRset in the Answer section, the name server 451 MUST also place its RRSIG RRs in the Answer section. The RRSIG 452 RRs have a higher priority for inclusion than any other RRsets 453 that may need to be included. If space does not permit inclusion 454 of these RRSIG RRs, the name server MUST set the TC bit. 456 o When placing a signed RRset in the Authority section, the name 457 server MUST also place its RRSIG RRs in the Authority section. 458 The RRSIG RRs have a higher priority for inclusion than any other 459 RRsets that may need to be included. If space does not permit 460 inclusion of these RRSIG RRs, the name server MUST set the TC bit. 461 o When placing a signed RRset in the Additional section, the name 462 server MUST also place its RRSIG RRs in the Additional section. 463 If space does not permit inclusion of both the RRset and its 464 associated RRSIG RRs, the name server MAY retain the RRset while 465 dropping the RRSIG RRs. If this happens, the name server MUST NOT 466 set the TC bit solely because these RRSIG RRs didn't fit. 468 3.1.2 Including DNSKEY RRs In a Response 470 When responding to a query that has the DO bit set and that requests 471 the SOA or NS RRs at the apex of a signed zone, a security-aware 472 authoritative name server for that zone MAY return the zone apex 473 DNSKEY RRset in the Additional section. In this situation, the 474 DNSKEY RRset and associated RRSIG RRs have lower priority than any 475 other information that would be placed in the additional section. 476 The name server SHOULD NOT include the DNSKEY RRset unless there is 477 enough space in the response message for both the DNSKEY RRset and 478 its associated RRSIG RR(s). If there is not enough space to include 479 these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST 480 NOT set the TC bit solely because these RRs didn't fit (see Section 481 3.1.1). 483 3.1.3 Including NSEC RRs In a Response 485 When responding to a query that has the DO bit set, a security-aware 486 authoritative name server for a signed zone MUST include NSEC RRs in 487 each of the following cases: 489 No Data: The zone contains RRsets that exactly match , 490 but does not contain any RRsets that exactly match . 493 Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. 496 Wildcard Answer: The zone does not contain any RRsets that exactly 497 match but does contain an RRset that matches 498 via wildcard name expansion. 500 Wildcard No Data: The zone does not contain any RRsets that exactly 501 match , does contain one or more RRsets that match 502 via wildcard name expansion, but does not contain 503 any RRsets that match via wildcard name 504 expansion. 506 In each of these cases, the name server includes NSEC RRs in the 507 response to prove that an exact match for was 508 not present in the zone and that the response that the name server is 509 returning is correct given the data that are in the zone. 511 3.1.3.1 Including NSEC RRs: No Data Response 513 If the zone contains RRsets matching but contains no 514 RRset matching , then the name server MUST 515 include the NSEC RR for along with its associated 516 RRSIG RR(s) in the Authority section of the response (see Section 517 3.1.1). If space does not permit inclusion of the NSEC RR or its 518 associated RRSIG RR(s), the name server MUST set the TC bit (see 519 Section 3.1.1). 521 Since the search name exists, wildcard name expansion does not apply 522 to this query, and a single signed NSEC RR suffices to prove the 523 requested RR type does not exist. 525 3.1.3.2 Including NSEC RRs: Name Error Response 527 If the zone does not contain any RRsets matching 528 either exactly or via wildcard name expansion, then the name server 529 MUST include the following NSEC RRs in the Authority section, along 530 with their associated RRSIG RRs: 531 o An NSEC RR proving that there is no exact match for ; and 533 o An NSEC RR proving that the zone contains no RRsets that would 534 match via wildcard name expansion. 536 In some cases a single NSEC RR may prove both of these points, in 537 that case the name server SHOULD only include the NSEC RR and its 538 RRSIG RR(s) once in the Authority section. 540 If space does not permit inclusion of these NSEC and RRSIG RRs, the 541 name server MUST set the TC bit (see Section 3.1.1). 543 The owner names of these NSEC and RRSIG RRs are not subject to 544 wildcard name expansion when these RRs are included in the Authority 545 section of the response. 547 Note that this form of response includes cases in which SNAME 548 corresponds to an empty non-terminal name within the zone (a name 549 which is not the owner name for any RRset but which is the parent 550 name of one or more RRsets). 552 3.1.3.3 Including NSEC RRs: Wildcard Answer Response 554 If the zone does not contain any RRsets which exactly match but does contain an RRset which matches via wildcard name expansion, the name server MUST include the 557 wildcard-expanded answer and the corresponding wildcard-expanded 558 RRSIG RRs in the Answer section, and MUST include in the Authority 559 section an NSEC RR and associated RRSIG RR(s) proving that the zone 560 does not contain a closer match for . If space does 561 not permit inclusion of the answer, NSEC and RRSIG RRs, the name 562 server MUST set the TC bit (see Section 3.1.1). 564 3.1.3.4 Including NSEC RRs: Wildcard No Data Response 566 This case is a combination of the previous cases. The zone does not 567 contain an exact match for , and while the zone does 568 contain RRsets which match via wildcard expansion, 569 none of those RRsets match STYPE. The name server MUST include the 570 following NSEC RRs in the Authority section, along with their 571 associated RRSIG RRs: 572 o An NSEC RR proving that there are no RRsets matching STYPE at the 573 wildcard owner name which matched via wildcard 574 expansion; and 575 o An NSEC RR proving that there are no RRsets in the zone which 576 would have been a closer match for . 578 In some cases a single NSEC RR may prove both of these points, in 579 which case the name server SHOULD only include the NSEC RR and its 580 RRSIG RR(s) once in the Authority section. 582 The owner names of these NSEC and RRSIG RRs are not subject to 583 wildcard name expansion when these RRs are included in the Authority 584 section of the response. 586 If space does not permit inclusion of these NSEC and RRSIG RRs, the 587 name server MUST set the TC bit (see Section 3.1.1). 589 3.1.3.5 Finding The Right NSEC RRs 591 As explained above, there are several situations in which a 592 security-aware authoritative name server needs to locate an NSEC RR 593 which proves that no RRsets matching a particular SNAME exist. 594 Locating such an NSEC RR within an authoritative zone is relatively 595 simple, at least in concept. The following discussion assumes that 596 the name server is authoritative for the zone which would have held 597 the nonexistent RRsets matching SNAME. The algorithm below is 598 written for clarity, not efficiency. 600 To find the NSEC which proves that no RRsets matching name N exist in 601 the zone Z which would have held them, construct sequence S 602 consisting of the owner names of every RRset in Z, sorted into 603 canonical order ([I-D.ietf-dnsext-dnssec-records]), with no duplicate 604 names. Find the name M which would have immediately preceded N in S 605 if any RRsets with owner name N had existed. M is the owner name of 606 the NSEC RR which proves that no RRsets exist with owner name N. 608 The algorithm for finding the NSEC RR which proves that a given name 609 is not covered by any applicable wildcard is similar, but requires an 610 extra step. More precisely, the algorithm for finding the NSEC 611 proving that no RRsets exist with the applicable wildcard name is 612 precisely the same as the algorithm for finding the NSEC RR which 613 proves that RRsets with any other owner name do not exist: the part 614 that's missing is how to determine the name of the nonexistent 615 applicable wildcard. In practice, this is easy, because the 616 authoritative name server has already checked for the presence of 617 precisely this wildcard name as part of step (1)(c) of the normal 618 lookup algorithm described in Section 4.3.2 of [RFC1034]. 620 3.1.4 Including DS RRs In a Response 622 When responding to a query which has the DO bit set, a security-aware 623 authoritative name server returning a referral includes DNSSEC data 624 along with the NS RRset. 626 If a DS RRset is present at the delegation point, the name server 627 MUST return both the DS RRset and its associated RRSIG RR(s) in the 628 Authority section along with the NS RRset. 630 If no DS RRset is present at the delegation point, the name server 631 MUST return both the NSEC RR which proves that the DS RRset is not 632 present and the NSEC RR's associated RRSIG RR(s) along with the NS 633 RRset. The name server MUST place the NS RRset before the NSEC RRset 634 and its associated RRSIG RR(s). 636 Including these DS, NSEC, and RRSIG RRs increases the size of 637 referral messages, and may cause some or all glue RRs to be omitted. 638 If space does not permit inclusion of the DS or NSEC RRset and 639 associated RRSIG RRs, the name server MUST set the TC bit (see 640 Section 3.1.1). 642 3.1.4.1 Responding to Queries for DS RRs 644 The DS resource record type is unusual in that it appears only on the 645 parent zone's side of a zone cut. For example, the DS RRset for the 646 delegation of "foo.example" is stored in the "example" zone rather 647 than in the "foo.example" zone. This requires special processing 648 rules for both name servers and resolvers, since the name server for 649 the child zone is authoritative for the name at the zone cut by the 650 normal DNS rules but the child zone does not contain the DS RRset. 652 A security-aware resolver sends queries to the parent zone when 653 looking for a needed DS RR at a delegation point (see Section 4.2). 654 However, special rules are necessary to avoid confusing 655 security-oblivious resolvers which might become involved in 656 processing such a query (for example, in a network configuration that 657 forces a security-aware resolver to channel its queries through a 658 security-oblivious recursive name server). The rest of this section 659 describes how a security-aware name server processes DS queries in 660 order to avoid this problem. 662 The need for special processing by a security-aware name server only 663 arises when all the following conditions are met: 664 o the name server has received a query for the DS RRset at a zone 665 cut; and 666 o the name server is authoritative for the child zone; and 667 o the name server is not authoritative for the parent zone; and 668 o the name server does not offer recursion. 670 In all other cases, the name server either has some way of obtaining 671 the DS RRset or could not have been expected to have the DS RRset 672 even by the pre-DNSSEC processing rules, so the name server can 673 return either the DS RRset or an error response according to the 674 normal processing rules. 676 If all of the above conditions are met, however, the name server is 677 authoritative for SNAME but cannot supply the requested RRset. In 678 this case, the name server MUST return an authoritative "no data" 679 response showing that the DS RRset does not exist in the child zone's 680 apex. See Appendix B.8 for an example of such a response. 682 3.1.5 Responding to Queries for Type AXFR or IXFR 684 DNSSEC does not change the DNS zone transfer process. A signed zone 685 will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these 686 records have no special meaning with respect to a zone transfer 687 operation. 689 An authoritative name server is not required to verify that a zone is 690 properly signed before sending or accepting a zone transfer. 691 However, an authoritative name server MAY choose to reject the entire 692 zone transfer if the zone fails meets any of the signing requirements 693 described in Section 2. The primary objective of a zone transfer is 694 to ensure that all authoritative name servers have identical copies 695 of the zone. An authoritative name server that chooses to perform 696 its own zone validation MUST NOT selectively reject some RRs and 697 accept others. 699 DS RRsets appear only on the parental side of a zone cut and are 700 authoritative data in the parent zone. As with any other 701 authoritative RRset, the DS RRset MUST be included in zone transfers 702 of the zone in which the RRset is authoritative data: in the case of 703 the DS RRset, this is the parent zone. 705 NSEC RRs appear in both the parent and child zones at a zone cut, and 706 are authoritative data in both the parent and child zones. The 707 parental and child NSEC RRs at a zone cut are never identical to each 708 other, since the NSEC RR in the child zone's apex will always 709 indicate the presence of the child zone's SOA RR while the parental 710 NSEC RR at the zone cut will never indicate the presence of an SOA 711 RR. As with any other authoritative RRs, NSEC RRs MUST be included 712 in zone transfers of the zone in which they are authoritative data: 713 the parental NSEC RR at a zone cut MUST be included in zone transfers 714 of the parent zone, while the NSEC at the zone apex of the child zone 715 MUST be included in zone transfers of the child zone. 717 RRSIG RRs appear in both the parent and child zones at a zone cut, 718 and are authoritative in whichever zone contains the authoritative 719 RRset for which the RRSIG RR provides the signature. That is, the 720 RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be 721 authoritative in the parent zone, while the RRSIG for any RRset in 722 the child zone's apex will be authoritative in the child zone. 723 Parental and child RRSIG RRs at a zone cut will never be identical to 724 each other, since the Signer's Name field of an RRSIG RR in the child 725 zone's apex will indicate a DNSKEY RR in the child zone's apex while 726 the same field of a parental RRSIG RR at the zone cut will indicate a 727 DNSKEY RR in the parent zone's apex. As with any other authoritative 728 RRs, RRSIG RRs MUST be included in zone transfers of the zone in 729 which they are authoritative data. 731 3.1.6 The AD and CD Bits in an Authoritative Response 733 The CD and AD bits are designed for use in communication between 734 security-aware resolvers and security-aware recursive name servers. 735 These bits are for the most part not relevant to query processing by 736 security-aware authoritative name servers. 738 A security-aware name server does not perform signature validation 739 for authoritative data during query processing even when the CD bit 740 is clear. A security-aware name server SHOULD clear the CD bit when 741 composing an authoritative response. 743 A security-aware name server MUST NOT set the AD bit in a response 744 unless the name server considers all RRsets in the Answer and 745 Authority sections of the response to be authentic. A security-aware 746 name server's local policy MAY consider data from an authoritative 747 zone to be authentic without further validation, but the name server 748 MUST NOT do so unless the name server obtained the authoritative zone 749 via secure means (such as a secure zone transfer mechanism), and MUST 750 NOT do so unless this behavior has been configured explicitly. 752 A security-aware name server which supports recursion MUST follow the 753 rules for the CD and AD bits given in Section 3.2 when generating a 754 response that involves data obtained via recursion. 756 3.2 Recursive Name Servers 758 As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware 759 recursive name server is an entity which acts in both the 760 security-aware name server and security-aware resolver roles. This 761 section uses the terms "name server side" and "resolver side" to 762 refer to the code within a security-aware recursive name server which 763 implements the security-aware name server role and the code which 764 implements the security-aware resolver role, respectively. 766 The resolver side follows the usual rules for caching and negative 767 caching which would apply to any security-aware resolver. 769 3.2.1 The DO bit 771 The resolver side of a security-aware recursive name server MUST set 772 the DO bit when sending requests, regardless of the state of the DO 773 bit in the initiating request received by the name server side. If 774 the DO bit in an initiating query is not set, the name server side 775 MUST strip any authenticating DNSSEC RRs from the response, but MUST 776 NOT strip any DNSSEC RR types that the initiating query explicitly 777 requested. 779 3.2.2 The CD bit 781 The CD bit exists in order to allow a security-aware resolver to 782 disable signature validation in a security-aware name server's 783 processing of a particular query. 785 The name server side MUST copy the setting of the CD bit from a query 786 to the corresponding response. 788 The name server side of a security-aware recursive name server MUST 789 pass the state of the CD bit to the resolver side along with the rest 790 of an initiating query, so that the resolver side will know whether 791 or not it is required to verify the response data it returns to the 792 name server side. If the CD bit is set, it indicates that the 793 originating resolver is willing to perform whatever authentication 794 its local policy requires, thus the resolver side of the recursive 795 name server need not perform authentication on the RRsets in the 796 response. When the CD bit is set the recursive name server SHOULD, 797 if possible, return the requested data to the originating resolver 798 even if the recursive name server's local authentication policy would 799 reject the records in question. That is, by setting the CD bit, the 800 originating resolver has indicated that it takes responsibility for 801 performing its own authentication, and the recursive name server 802 should not interfere. 804 If the resolver side implements a BAD cache (see Section 4.7) and the 805 name server side receives a query which matches an entry in the 806 resolver side's BAD cache, the name server side's response depends on 807 the state of the CD bit in the original query. If the CD bit is set, 808 the name server side SHOULD return the data from the BAD cache; if 809 the CD bit is not set, the name server side MUST return RCODE 2 810 (server failure). 812 The intent of the above rule is to provide the raw data to clients 813 which are capable of performing their own signature verification 814 checks while protecting clients which depend on the resolver side of 815 a security-aware recursive name server to perform such checks. 816 Several of the possible reasons why signature validation might fail 817 involve conditions which may not apply equally to the recursive name 818 server and the client which invoked it: for example, the recursive 819 name server's clock may be set incorrectly, or the client may have 820 knowledge of a relevant island of security which the recursive name 821 server does not share. In such cases, "protecting" a client which is 822 capable of performing its own signature validation from ever seeing 823 the "bad" data does not help the client. 825 3.2.3 The AD bit 827 The name server side of a security-aware recursive name server MUST 828 NOT set the AD bit in a response unless the name server considers all 829 RRsets in the Answer and Authority sections of the response to be 830 authentic. The name server side SHOULD set the AD bit if and only if 831 the resolver side considers all RRsets in the Answer section and any 832 relevant negative response RRs in the Authority section to be 833 authentic. The resolver side MUST follow the procedure described in 834 Section 5 to determine whether the RRs in question are authentic. 835 However, for backwards compatibility, a recursive name server MAY set 836 the AD bit when a response includes unsigned CNAME RRs if those CNAME 837 RRs demonstrably could have been synthesized from an authentic DNAME 838 RR which is also included in the response according to the synthesis 839 rules described in [RFC2672]. 841 3.3 Example DNSSEC Responses 843 See Appendix B for example response packets. 845 4. Resolving 847 This section describes the behavior of entities that include 848 security-aware resolver functions. In many cases such functions will 849 be part of a security-aware recursive name server, but a stand-alone 850 security-aware resolver has many of the same requirements. Functions 851 specific to security-aware recursive name servers are described in 852 Section 3.2. 854 4.1 EDNS Support 856 A security-aware resolver MUST include an EDNS ([RFC2671]) OPT 857 pseudo-RR with the DO ([RFC3225]) bit set when sending queries. 859 A security-aware resolver MUST support a message size of at least 860 1220 octets, SHOULD support a message size of 4000 octets, and MUST 861 advertise the message size it's willing to accept using the "sender's 862 UDP payload size" field in the EDNS OPT pseudo-RR. A security-aware 863 resolver's IP layer MUST handle fragmented UDP packets correctly 864 regardless of whether any such fragmented packets were received via 865 IPv4 or IPv6. Please see [RFC1122], [RFC2460] and [RFC3226] for 866 discussion of these requirements. 868 4.2 Signature Verification Support 870 A security-aware resolver MUST support the signature verification 871 mechanisms described in Section 5, and SHOULD apply them to every 872 received response except when: 873 o The security-aware resolver is part of a security-aware recursive 874 name server, and the response is the result of recursion on behalf 875 of a query received with the CD bit set; 876 o The response is the result of a query generated directly via some 877 form of application interface which instructed the security-aware 878 resolver not to perform validation for this query; or 879 o Validation for this query has been disabled by local policy. 881 A security-aware resolver's support for signature verification MUST 882 include support for verification of wildcard owner names. 884 Security aware resolvers MAY query for missing security RRs in an 885 attempt to perform validation; implementations that choose to do so 886 must be aware that the answers received may not be sufficient to 887 validate the original response. For example, a zone update may have 888 changed (or deleted) the desired information between the original and 889 follow-up queries. 891 When attempting to retrieve missing NSEC RRs which reside on the 892 parental side at a zone cut, a security-aware iterative-mode resolver 893 MUST query the name servers for the parent zone, not the child zone. 895 When attempting to retrieve a missing DS, a security-aware 896 iterative-mode resolver MUST query the name servers for the parent 897 zone, not the child zone. As explained in Section 3.1.4.1, 898 security-aware name servers need to apply special processing rules to 899 handle the DS RR, and in some situations the resolver may also need 900 to apply special rules to locate the name servers for the parent zone 901 if the resolver does not already have the parent's NS RRset. To 902 locate the parent NS RRset, the resolver can start with the 903 delegation name, strip off the leftmost label, and query for an NS 904 RRset by that name; if no NS RRset is present at that name, the 905 resolver then strips off the leftmost remaining label and retries the 906 query for that name, repeating this process of walking up the tree 907 until it either finds the NS RRset or runs out of labels. 909 4.3 Determining Security Status of Data 911 A security-aware resolver MUST be able to determine whether or not it 912 should expect a particular RRset to be signed. More precisely, a 913 security-aware resolver must be able to distinguish between four 914 cases: 916 Secure: An RRset for which the resolver is able to build a chain of 917 signed DNSKEY and DS RRs from a trusted security anchor to the 918 RRset. In this case, the RRset should be signed, and is subject 919 to signature validation as described above. 921 Insecure: An RRset for which the resolver knows that it has no chain 922 of signed DNSKEY and DS RRs from any trusted starting point to the 923 RRset. This can occur when the target RRset lies in an unsigned 924 zone or in a descendent of an unsigned zone. In this case, the 925 RRset may or may not be signed, but the resolver will not be able 926 to verify the signature. 928 Bogus: An RRset for which the resolver believes that it ought to be 929 able to establish a chain of trust but is unable to do so, either 930 due to signatures that for some reason fail to validate or due to 931 missing data which the relevant DNSSEC RRs indicate should be 932 present. This case may indicate an attack, but may also indicate 933 a configuration error or some form of data corruption. 935 Indeterminate: An RRset for which the resolver is not able to 936 determine whether or not the RRset should be signed, because the 937 resolver is not able to obtain the necessary DNSSEC RRs. This can 938 occur when the security-aware resolver is not able to contact 939 security-aware name servers for the relevant zones. 941 4.4 Configured Trust Anchors 943 A security-aware resolver MUST be capable of being configured with at 944 least one trusted public key or DS RR, and SHOULD be capable of being 945 configured with multiple trusted public keys or DS RRs. Since a 946 security-aware resolver will not be able to validate signatures 947 without such a configured trust anchor, the resolver SHOULD have some 948 reasonably robust mechanism for obtaining such keys when it boots; 949 examples of such a mechanism would be some form of non-volatile 950 storage (such as a disk drive) or some form of trusted local network 951 configuration mechanism. 953 Note that trust anchors also covers key material that is updated in a 954 secure manner. This secure manner could be through physical media, a 955 key exchange protocol, or some other out of band means. 957 4.5 Response Caching 959 A security-aware resolver SHOULD cache each response as a single 960 atomic entry containing the entire answer, including the named RRset 961 and any associated DNSSEC RRs. The resolver SHOULD discard the 962 entire atomic entry when any of the RRs contained in it expire. In 963 most cases the appropriate cache index for the atomic entry will be 964 the triple , but in cases such as the response 965 form described in Section 3.1.3.2 the appropriate cache index will be 966 the double . 968 The reason for these recommendations is that, between the initial 969 query and the expiration of the data from the cache, the 970 authoritative data might have been changed (for example, via dynamic 971 update). 973 There are two situations for which this is relevant: 974 1. By using the RRSIG record, it is possible to deduce that an 975 answer was synthesized from a wildcard. A security aware 976 recursive name server could store this wildcard data and use it 977 to generate positive responses to queries other than the name for 978 which the original answer was first received. 979 2. NSEC RRs received to prove the non-existence of a name could be 980 reused by a security aware resolver to prove the non-existence of 981 any name in the name range it spans. 983 In theory, a resolver could use wildcards or NSEC RRs to generate 984 positive and negative responses (respectively) until the TTL or 985 signatures on the records in question expire. However, it seems 986 prudent for resolvers to avoid blocking new authoritative data or 987 synthesizing new data on their own. Resolvers which follow this 988 recommendation will have a more consistent view of the namespace. 990 4.6 Handling of the CD and AD bits 992 A security-aware resolver MAY set a query's CD bit in order to 993 indicate that the resolver takes responsibility for performing 994 whatever authentication its local policy requires on the RRsets in 995 the response. See Section 3.2 for the effect this bit has on the 996 behavior of security-aware recursive name servers. 998 A security-aware resolver MUST clear the AD bit when composing query 999 messages to protect against buggy name servers which blindly copy 1000 header bits which they do not understand from the query message to 1001 the response message. 1003 A resolver MUST disregard the meaning of the CD and AD bits in a 1004 response unless the response was obtained using a secure channel or 1005 the resolver was specifically configured to regard the message header 1006 bits without using a secure channel. 1008 4.7 Caching BAD Data 1010 While many validation errors will be transient, some are likely to be 1011 more persistent, such as those caused by administrative error 1012 (failure to re-sign a zone, clock skew, and so forth). Since 1013 requerying will not help in these cases, validating resolvers might 1014 generate a significant amount of unnecessary DNS traffic as a result 1015 of repeated queries for RRsets with persistent validation failures. 1017 To prevent such unnecessary DNS traffic, security-aware resolvers MAY 1018 cache data with invalid signatures, with some restrictions. 1019 Conceptually, caching such data is similar to negative caching 1020 ([RFC2308]), except that instead of caching a valid negative 1021 response, the resolver is caching the fact that a particular answer 1022 failed to validate. This document refers to a cache of data with 1023 invalid signatures as a "BAD cache". 1025 Resolvers which implement a BAD cache MUST take steps to prevent the 1026 cache from being useful as a denial-of-service attack amplifier. In 1027 particular: 1028 o Since RRsets which fail to validate do not have trustworthy TTLs, 1029 the implementation MUST assign a TTL. This TTL SHOULD be small, 1030 in order to mitigate the effect of caching the results of an 1031 attack. 1032 o In order to prevent caching of a transient validation failure 1033 (which might be the result of an attack), resolvers SHOULD track 1034 queries that result in validation failures, and SHOULD only answer 1035 from the BAD cache after the number of times that responses to 1036 queries for that particular have failed to 1037 validate exceeds a threshold value. 1039 Resolvers MUST NOT return RRsets from the BAD cache unless the 1040 resolver is not required to validate the signatures of the RRsets in 1041 question under the rules given in Section 4.2 of this document. See 1042 Section 3.2.2 for discussion of how the responses returned by a 1043 security-aware recursive name server interact with a BAD cache. 1045 4.8 Synthesized CNAMEs 1047 A validating security-aware resolver MUST treat the signature of a 1048 valid signed DNAME RR as also covering unsigned CNAME RRs which could 1049 have been synthesized from the DNAME RR as described in [RFC2672], at 1050 least to the extent of not rejecting a response message solely 1051 because it contains such CNAME RRs. The resolver MAY retain such 1052 CNAME RRs in its cache or in the answers it hands back, but is not 1053 required to do so. 1055 4.9 Stub resolvers 1057 A security-aware stub resolver MUST support the DNSSEC RR types, at 1058 least to the extent of not mishandling responses just because they 1059 contain DNSSEC RRs. 1061 4.9.1 Handling of the DO Bit 1063 A non-validating security-aware stub resolver MAY include the DNSSEC 1064 RRs returned by a security-aware recursive name server as part of the 1065 data that the stub resolver hands back to the application which 1066 invoked it but is not required to do so. A non-validating stub 1067 resolver that wishes to do this will need to set the DO bit in 1068 receive DNSSEC RRs from the recursive name server. 1070 A validating security-aware stub resolver MUST set the DO bit, since 1071 otherwise it will not receive the DNSSEC RRs it needs to perform 1072 signature validation. 1074 4.9.2 Handling of the CD Bit 1076 A non-validating security-aware stub resolver SHOULD NOT set the CD 1077 bit when sending queries unless requested by the application layer, 1078 since by definition, a non-validating stub resolver depends on the 1079 security-aware recursive name server to perform validation on its 1080 behalf. 1082 A validating security-aware stub resolver SHOULD set the CD bit, 1083 since otherwise the security-aware recursive name server will answer 1084 the query using the name server's local policy, which may prevent the 1085 stub resolver from receiving data which would be acceptable to the 1086 stub resolver's local policy. 1088 4.9.3 Handling of the AD Bit 1090 A non-validating security-aware stub resolver MAY chose to examine 1091 the setting of the AD bit in response messages that it receives in 1092 order to determine whether the security-aware recursive name server 1093 which sent the response claims to have cryptographically verified the 1094 data in the Answer and Authority sections of the response message. 1095 Note, however, that the responses received by a security-aware stub 1096 resolver are heavily dependent on the local policy of the 1097 security-aware recursive name server, so as a practical matter there 1098 may be little practical value to checking the status of the AD bit 1099 except perhaps as a debugging aid. In any case, a security-aware 1100 stub resolver MUST NOT place any reliance on signature validation 1101 allegedly performed on its behalf except when the security-aware stub 1102 resolver obtained the data in question from a trusted security-aware 1103 recursive name server via a secure channel. 1105 A validating security-aware stub resolver SHOULD NOT examine the 1106 setting of the AD bit in response messages, since, by definition, the 1107 stub resolver performs its own signature validation regardless of the 1108 setting of the AD bit. 1110 5. Authenticating DNS Responses 1112 In order to use DNSSEC RRs for authentication, a security-aware 1113 resolver requires configured knowledge of at least one authenticated 1114 DNSKEY or DS RR. The process for obtaining and authenticating this 1115 initial trust anchors is achieved via some external mechanism. For 1116 example, a resolver could use some off-line authenticated exchange to 1117 obtain a zone's DNSKEY RR or obtain a DS RR that identifies and 1118 authenticates a zone's DNSKEY RR. The remainder of this section 1119 assumes that the resolver has somehow obtained an initial set of 1120 trust anchors. 1122 An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY 1123 RRset. To authenticate an apex DNSKEY RRset using an initial key, 1124 the resolver MUST: 1125 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY 1126 RRset, and verify that the DNSKEY RR has the Zone Key Flag 1127 (DNSKEY RDATA bit 7) set. 1128 2. Verify that there is some RRSIG RR that covers the apex DNSKEY 1129 RRset, and that the combination of the RRSIG RR and the initial 1130 DNSKEY RR authenticates the DNSKEY RRset. The process for using 1131 an RRSIG RR to authenticate an RRset is described in Section 5.3. 1133 Once the resolver has authenticated the apex DNSKEY RRset using an 1134 initial DNSKEY RR, delegations from that zone can be authenticated 1135 using DS RRs. This allows a resolver to start from an initial key, 1136 and use DS RRsets to proceed recursively down the DNS tree obtaining 1137 other apex DNSKEY RRsets. If the resolver were configured with a 1138 root DNSKEY RR, and if every delegation had a DS RR associated with 1139 it, then the resolver could obtain and validate any apex DNSKEY 1140 RRset. The process of using DS RRs to authenticate referrals is 1141 described in Section 5.2. 1143 Once the resolver has authenticated a zone's apex DNSKEY RRset, 1144 Section 5.3 shows how the resolver can use DNSKEY RRs in the apex 1145 DNSKEY RRset and RRSIG RRs from the zone to authenticate any other 1146 RRsets in the zone. Section 5.4 shows how the resolver can use 1147 authenticated NSEC RRsets from the zone to prove that an RRset is not 1148 present in the zone. 1150 When a resolver indicates support for DNSSEC (by setting the DO bit), 1151 a security-aware name server should attempt to provide the necessary 1152 DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). 1153 However, a security-aware resolver may still receive a response that 1154 lacks the appropriate DNSSEC RRs, whether due to configuration issues 1155 such as an upstream security-oblivious recursive name server that 1156 accidentally interferes with DNSSEC RRs or due to a deliberate attack 1157 in which an adversary forges a response, strips DNSSEC RRs from a 1158 response, or modifies a query so that DNSSEC RRs appear not to be 1159 requested. The absence of DNSSEC data in a response MUST NOT by 1160 itself be taken as an indication that no authentication information 1161 exists. 1163 A resolver SHOULD expect authentication information from signed 1164 zones. A resolver SHOULD believe that a zone is signed if the 1165 resolver has been configured with public key information for the 1166 zone, or if the zone's parent is signed and the delegation from the 1167 parent contains a DS RRset. 1169 5.1 Special Considerations for Islands of Security 1171 Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed 1172 zones for which it is not possible to construct an authentication 1173 chain to the zone from its parent. Validating signatures within an 1174 island of security requires the validator to have some other means of 1175 obtaining an initial authenticated zone key for the island. If a 1176 validator cannot obtain such a key, it SHOULD switch to operating as 1177 if the zones in the island of security are unsigned. 1179 All the normal processes for validating responses apply to islands of 1180 security. The only difference between normal validation and 1181 validation within an island of security is in how the validator 1182 obtains a trust anchor for the authentication chain. 1184 5.2 Authenticating Referrals 1186 Once the apex DNSKEY RRset for a signed parent zone has been 1187 authenticated, DS RRsets can be used to authenticate the delegation 1188 to a signed child zone. A DS RR identifies a DNSKEY RR in the child 1189 zone's apex DNSKEY RRset, and contains a cryptographic digest of the 1190 child zone's DNSKEY RR. Use of a strong cryptographic digest 1191 algorithm ensures that it is computationally infeasible for an 1192 adversary to generate a DNSKEY RR that matches the digest. Thus, 1193 authenticating the digest allows a resolver to authenticate the 1194 matching DNSKEY RR. The resolver can then use this child DNSKEY RR 1195 to authenticate the entire child apex DNSKEY RRset. 1197 Given a DS RR for a delegation, the child zone's apex DNSKEY RRset 1198 can be authenticated if all of the following hold: 1199 o The DS RR has been authenticated using some DNSKEY RR in the 1200 parent's apex DNSKEY RRset (see Section 5.3); 1201 o The Algorithm and Key Tag in the DS RR match the Algorithm field 1202 and the key tag of a DNSKEY RR in the child zone's apex DNSKEY 1203 RRset and, when the DNSKEY RR's owner name and RDATA are hashed 1204 using the digest algorithm specified in the DS RR's Digest Type 1205 field, the resulting digest value matches the Digest field of the 1206 DS RR; and 1207 o The matching DNSKEY RR in the child zone has the Zone Flag bit 1208 set, the corresponding private key has signed the child zone's 1209 apex DNSKEY RRset, and the resulting RRSIG RR authenticates the 1210 child zone's apex DNSKEY RRset. 1212 If the referral from the parent zone did not contain a DS RRset, the 1213 response should have included a signed NSEC RRset proving that no DS 1214 RRset exists for the delegated name (see Section 3.1.4). A 1215 security-aware resolver MUST query the name servers for the parent 1216 zone for the DS RRset if the referral includes neither a DS RRset nor 1217 a NSEC RRset proving that the DS RRset does not exist (see Section 1218 4). 1220 If the validator authenticates an NSEC RRset that proves that no DS 1221 RRset is present for this zone, then there is no authentication path 1222 leading from the parent to the child. If the resolver has an initial 1223 DNSKEY or DS RR that belongs to the child zone or to any delegation 1224 below the child zone, this initial DNSKEY or DS RR MAY be used to 1225 re-establish an authentication path. If no such initial DNSKEY or DS 1226 RR exists, the validator can not authenticate RRsets in or below the 1227 child zone. 1229 If the validator does not support any of the algorithms listed in an 1230 authenticated DS RRset, then the resolver has no supported 1231 authentication path leading from the parent to the child. The 1232 resolver should treat this case as it would the case of an 1233 authenticated NSEC RRset proving that no DS RRset exists, as 1234 described above. 1236 Note that, for a signed delegation, there are two NSEC RRs associated 1237 with the delegated name. One NSEC RR resides in the parent zone, and 1238 can be used to prove whether a DS RRset exists for the delegated 1239 name. The second NSEC RR resides in the child zone, and identifies 1240 which RRsets are present at the apex of the child zone. The parent 1241 NSEC RR and child NSEC RR can always be distinguished, since the SOA 1242 bit will be set in the child NSEC RR and clear in the parent NSEC RR. 1243 A security-aware resolver MUST use the parent NSEC RR when attempting 1244 to prove that a DS RRset does not exist. 1246 If the resolver does not support any of the algorithms listed in an 1247 authenticated DS RRset, then the resolver will not be able to verify 1248 the authentication path to the child zone. In this case, the 1249 resolver SHOULD treat the child zone as if it were unsigned. 1251 5.3 Authenticating an RRset Using an RRSIG RR 1253 A validator can use an RRSIG RR and its corresponding DNSKEY RR to 1254 attempt to authenticate RRsets. The validator first checks the RRSIG 1255 RR to verify that it covers the RRset, has a valid time interval, and 1256 identifies a valid DNSKEY RR. The validator then constructs the 1257 canonical form of the signed data by appending the RRSIG RDATA 1258 (excluding the Signature Field) with the canonical form of the 1259 covered RRset. Finally, the validator uses the public key and 1260 signature to authenticate the signed data. Section 5.3.1, Section 1261 5.3.2, and Section 5.3.3 describe each step in detail. 1263 5.3.1 Checking the RRSIG RR Validity 1265 A security-aware resolver can use an RRSIG RR to authenticate an 1266 RRset if all of the following conditions hold: 1267 o The RRSIG RR and the RRset MUST have the same owner name and the 1268 same class; 1269 o The RRSIG RR's Signer's Name field MUST be the name of the zone 1270 that contains the RRset; 1271 o The RRSIG RR's Type Covered field MUST equal the RRset's type; 1272 o The number of labels in the RRset owner name MUST be greater than 1273 or equal to the value in the RRSIG RR's Labels field; 1274 o The validator's notion of the current time MUST be less than or 1275 equal to the time listed in the RRSIG RR's Expiration field; 1276 o The validator's notion of the current time MUST be greater than or 1277 equal to the time listed in the RRSIG RR's Inception field; 1278 o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST 1279 match the owner name, algorithm, and key tag for some DNSKEY RR in 1280 the zone's apex DNSKEY RRset; 1281 o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY 1282 RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) 1283 set. 1285 It is possible for more than one DNSKEY RR to match the conditions 1286 above. In this case, the validator cannot predetermine which DNSKEY 1287 RR to use to authenticate the signature, MUST try each matching 1288 DNSKEY RR until either the signature is validated or the validator 1289 has run out of matching public keys to try. 1291 Note that this authentication process is only meaningful if the 1292 validator authenticates the DNSKEY RR before using it to validate 1293 signatures. The matching DNSKEY RR is considered to be authentic if: 1294 o The apex DNSKEY RRset containing the DNSKEY RR is considered 1295 authentic; or 1296 o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, 1297 and the DNSKEY RR either matches an authenticated DS RR from the 1298 parent zone or matches a trust anchor. 1300 5.3.2 Reconstructing the Signed Data 1301 Once the RRSIG RR has met the validity requirements described in 1302 Section 5.3.1, the validator needs to reconstruct the original signed 1303 data. The original signed data includes RRSIG RDATA (excluding the 1304 Signature field) and the canonical form of the RRset. Aside from 1305 being ordered, the canonical form of the RRset might also differ from 1306 the received RRset due to DNS name compression, decremented TTLs, or 1307 wildcard expansion. The validator should use the following to 1308 reconstruct the original signed data: 1310 signed_data = RRSIG_RDATA | RR(1) | RR(2)... where 1312 "|" denotes concatenation 1314 RRSIG_RDATA is the wire format of the RRSIG RDATA fields 1315 with the Signature field excluded and the Signer's Name 1316 in canonical form. 1318 RR(i) = name | type | class | OrigTTL | RDATA length | RDATA 1320 name is calculated according to the function below 1322 class is the RRset's class 1324 type is the RRset type and all RRs in the class 1326 OrigTTL is the value from the RRSIG Original TTL field 1328 All names in the RDATA field are in canonical form 1330 The set of all RR(i) is sorted into canonical order. 1332 To calculate the name: 1333 let rrsig_labels = the value of the RRSIG Labels field 1335 let fqdn = RRset's fully qualified domain name in 1336 canonical form 1338 let fqdn_labels = Label count of the fqdn above. 1340 if rrsig_labels = fqdn_labels, 1341 name = fqdn 1343 if rrsig_labels < fqdn_labels, 1344 name = "*." | the rightmost rrsig_label labels of the 1345 fqdn 1347 if rrsig_labels > fqdn_labels 1348 the RRSIG RR did not pass the necessary validation 1349 checks and MUST NOT be used to authenticate this 1350 RRset. 1352 The canonical forms for names and RRsets are defined in 1353 [I-D.ietf-dnsext-dnssec-records]. 1355 NSEC RRsets at a delegation boundary require special processing. 1356 There are two distinct NSEC RRsets associated with a signed delegated 1357 name. One NSEC RRset resides in the parent zone, and specifies which 1358 RRset are present at the parent zone. The second NSEC RRset resides 1359 at the child zone, and identifies which RRsets are present at the 1360 apex in the child zone. The parent NSEC RRset and child NSEC RRset 1361 can always be distinguished since only the child NSEC RRs will 1362 specify an SOA RRset exists at the name. When reconstructing the 1363 original NSEC RRset for the delegation from the parent zone, the NSEC 1364 RRs MUST NOT be combined with NSEC RRs from the child zone, and when 1365 reconstructing the original NSEC RRset for the apex of the child 1366 zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent 1367 zone. 1369 Note also that each of the two NSEC RRsets at a delegation point has 1370 a corresponding RRSIG RR with an owner name matching the delegated 1371 name, and each of these RRSIG RRs is authoritative data associated 1372 with the same zone that contains the corresponding NSEC RRset. If 1373 necessary, a resolver can tell these RRSIG RRs apart by checking the 1374 Signer's Name field. 1376 5.3.3 Checking the Signature 1378 Once the resolver has validated the RRSIG RR as described in Section 1379 5.3.1 and reconstructed the original signed data as described in 1380 Section 5.3.2, the validator can attempt to use the cryptographic 1381 signature to authenticate the signed data, and thus (finally!) 1382 authenticate the RRset. 1384 The Algorithm field in the RRSIG RR identifies the cryptographic 1385 algorithm used to generate the signature. The signature itself is 1386 contained in the Signature field of the RRSIG RDATA, and the public 1387 key used to verify the signature is contained in the Public Key field 1388 of the matching DNSKEY RR(s) (found in Section 5.3.1). 1389 [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types 1390 and provides pointers to the documents that define each algorithm's 1391 use. 1393 Note that it is possible for more than one DNSKEY RR to match the 1394 conditions in Section 5.3.1. In this case, the validator can only 1395 determine which DNSKEY RR by trying each matching public key until 1396 the validator either succeeds in validating the signature or runs out 1397 of keys to try. 1399 If the Labels field of the RRSIG RR is not equal to the number of 1400 labels in the RRset's fully qualified owner name, then the RRset is 1401 either invalid or the result of wildcard expansion. The resolver 1402 MUST verify that wildcard expansion was applied properly before 1403 considering the RRset to be authentic. Section 5.3.4 describes how 1404 to determine whether a wildcard was applied properly. 1406 If other RRSIG RRs also cover this RRset, the local resolver security 1407 policy determines whether the resolver also needs to test these RRSIG 1408 RRs, and determines how to resolve conflicts if these RRSIG RRs lead 1409 to differing results. 1411 If the resolver accepts the RRset as authentic, the validator MUST 1412 set the TTL of the RRSIG RR and each RR in the authenticated RRset to 1413 a value no greater than the minimum of: 1414 o The RRset's TTL as received in the response; 1415 o The RRSIG RR's TTL as received in the response; 1416 o The value in the RRSIG RR's Original TTL field; and 1417 o The difference of the RRSIG RR's Signature Expiration time and the 1418 current time. 1420 5.3.4 Authenticating A Wildcard Expanded RRset Positive Response 1422 If the number of labels in an RRset's owner name is greater than the 1423 Labels field of the covering RRSIG RR, then the RRset and its 1424 covering RRSIG RR were created as a result of wildcard expansion. 1425 Once the validator has verified the signature as described in Section 1426 5.3, it must take additional steps to verify the non-existence of an 1427 exact match or closer wildcard match for the query. Section 5.4 1428 discusses these steps. 1430 Note that the response received by the resolver should include all 1431 NSEC RRs needed to authenticate the response (see Section 3.1.3). 1433 5.4 Authenticated Denial of Existence 1435 A resolver can use authenticated NSEC RRs to prove that an RRset is 1436 not present in a signed zone. Security-aware name servers should 1437 automatically include any necessary NSEC RRs for signed zones in 1438 their responses to security-aware resolvers. 1440 Denial of existence is determined by the following rules: 1441 o If the requested RR name matches the owner name of an 1442 authenticated NSEC RR, then the NSEC RR's type bit map field lists 1443 all RR types present at that owner name, and a resolver can prove 1444 that the requested RR type does not exist by checking for the RR 1445 type in the bit map. If the number of labels in an authenticated 1446 NSEC RR's owner name equals the Labels field of the covering RRSIG 1447 RR, then the existence of the NSEC RR proves that wildcard 1448 expansion could not have been used to match the request. 1449 o If the requested RR name would appear after an authenticated NSEC 1450 RR's owner name and before the name listed in that NSEC RR's Next 1451 Domain Name field according to the canonical DNS name order 1452 defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with 1453 the requested name exist in the zone. However, it is possible 1454 that a wildcard could be used to match the requested RR owner name 1455 and type, so proving that the requested RRset does not exist also 1456 requires proving that no possible wildcard RRset exists that could 1457 have been used to generate a positive response. 1459 In addition, security-aware resolvers MUST authenticate the NSEC 1460 RRsets that comprise the non-existence proof as described in Section 1461 5.3. 1463 To prove non-existence of an RRset, the resolver must be able to 1464 verify both that the queried RRset does not exist and that no 1465 relevant wildcard RRset exists. Proving this may require more than 1466 one NSEC RRset from the zone. If the complete set of necessary NSEC 1467 RRsets is not present in a response (perhaps due to message 1468 truncation), then a security-aware resolver MUST resend the query in 1469 order to attempt to obtain the full collection of NSEC RRs necessary 1470 to verify non-existence of the requested RRset. As with all DNS 1471 operations, however, the resolver MUST bound the work it puts into 1472 answering any particular query. 1474 Since a validated NSEC RR proves the existence of both itself and its 1475 corresponding RRSIG RR, a validator MUST ignore the settings of the 1476 NSEC and RRSIG bits in an NSEC RR. 1478 5.5 Resolver Behavior When Signatures Do Not Validate 1480 If for whatever reason none of the RRSIGs can be validated, the 1481 response SHOULD be considered BAD. If the validation was being done 1482 to service a recursive query, the name server MUST return RCODE 2 to 1483 the originating client. However, it MUST return the full response if 1484 and only if the original query had the CD bit set. See also Section 1485 4.7 on caching responses that do not validate. 1487 5.6 Authentication Example 1489 Appendix C shows an example of the authentication process. 1491 6. IANA Considerations 1493 [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA 1494 considerations introduced by DNSSEC. The additional IANA 1495 considerations discussed in this document: 1497 [RFC2535] reserved the CD and AD bits in the message header. The 1498 meaning of the AD bit was redefined in [RFC3655] and the meaning of 1499 both the CD and AD bit are restated in this document. No new bits in 1500 the DNS message header are defined in this document. 1502 [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit 1503 and defined its use. The use is restated but not altered in this 1504 document. 1506 7. Security Considerations 1508 This document describes how the DNS security extensions use public 1509 key cryptography to sign and authenticate DNS resource record sets. 1510 Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general 1511 security considerations related to DNSSEC; see 1512 [I-D.ietf-dnsext-dnssec-records] for considerations specific to the 1513 DNSSEC resource record types. 1515 An active attacker who can set the CD bit in a DNS query message or 1516 the AD bit in a DNS response message can use these bits to defeat the 1517 protection which DNSSEC attempts to provide to security-oblivious 1518 recursive-mode resolvers. For this reason, use of these control bits 1519 by a security-aware recursive-mode resolver requires a secure 1520 channel. See Section 3.2.2 and Section 4.9 for further discussion. 1522 The protocol described in this document attempts to extend the 1523 benefits of DNSSEC to security-oblivious stub resolvers. However, 1524 since recovery from validation failures is likely to be specific to 1525 particular applications, the facilities that DNSSEC provides for stub 1526 resolvers may prove inadequate. Operators of security-aware 1527 recursive name servers will need to pay close attention to the 1528 behavior of the applications which use their services when choosing a 1529 local validation policy; failure to do so could easily result in the 1530 recursive name server accidentally denying service to the clients it 1531 is intended to support. 1533 8. Acknowledgements 1535 This document was created from the input and ideas of the members of 1536 the DNS Extensions Working Group and working group mailing list. The 1537 editors would like to express their thanks for the comments and 1538 suggestions received during the revision of these security extension 1539 specifications. While explicitly listing everyone who has 1540 contributed during the decade during which DNSSEC has been under 1541 development would be an impossible task, 1542 [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the 1543 participants who were kind enough to comment on these documents. 1545 9. References 1547 9.1 Normative References 1549 [I-D.ietf-dnsext-dnssec-intro] 1550 Arends, R., Austein, R., Larson, M., Massey, D. and S. 1551 Rose, "DNS Security Introduction and Requirements", 1552 draft-ietf-dnsext-dnssec-intro-10 (work in progress), May 1553 2004. 1555 [I-D.ietf-dnsext-dnssec-records] 1556 Arends, R., Austein, R., Larson, M., Massey, D. and S. 1557 Rose, "Resource Records for DNS Security Extensions", 1558 draft-ietf-dnsext-dnssec-records-08 (work in progress), 1559 May 2004. 1561 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1562 STD 13, RFC 1034, November 1987. 1564 [RFC1035] Mockapetris, P., "Domain names - implementation and 1565 specification", STD 13, RFC 1035, November 1987. 1567 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1568 Communication Layers", STD 3, RFC 1122, October 1989. 1570 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1571 August 1996. 1573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1574 Requirement Levels", BCP 14, RFC 2119, March 1997. 1576 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1577 Specification", RFC 2181, July 1997. 1579 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1580 (IPv6) Specification", RFC 2460, December 1998. 1582 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 1583 2671, August 1999. 1585 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 1586 2672, August 1999. 1588 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 1589 3225, December 2001. 1591 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 1592 message size requirements", RFC 3226, December 2001. 1594 9.2 Informative References 1596 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1597 NCACHE)", RFC 2308, March 1998. 1599 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1600 RFC 2535, March 1999. 1602 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 1603 RR)", RFC 2930, September 2000. 1605 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 1606 SIG(0)s)", RFC 2931, September 2000. 1608 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1609 Update", RFC 3007, November 2000. 1611 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 1612 Authenticated Data (AD) bit", RFC 3655, November 2003. 1614 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 1615 (RR)", RFC 3658, December 2003. 1617 [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) 1618 RDATA Format", RFC 3845, August 2004. 1620 Authors' Addresses 1622 Roy Arends 1623 Telematica Instituut 1624 Drienerlolaan 5 1625 7522 NB Enschede 1626 NL 1628 EMail: roy.arends@telin.nl 1630 Rob Austein 1631 Internet Systems Consortium 1632 950 Charter Street 1633 Redwood City, CA 94063 1634 USA 1636 EMail: sra@isc.org 1637 Matt Larson 1638 VeriSign, Inc. 1639 21345 Ridgetop Circle 1640 Dulles, VA 20166-6503 1641 USA 1643 EMail: mlarson@verisign.com 1645 Dan Massey 1646 USC Information Sciences Institute 1647 3811 N. Fairfax Drive 1648 Arlington, VA 22203 1649 USA 1651 EMail: masseyd@isi.edu 1653 Scott Rose 1654 National Institute for Standards and Technology 1655 100 Bureau Drive 1656 Gaithersburg, MD 20899-8920 1657 USA 1659 EMail: scott.rose@nist.gov 1661 Appendix A. Signed Zone Example 1663 The following example shows a (small) complete signed zone. 1665 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1666 1081539377 1667 3600 1668 300 1669 3600000 1670 3600 1671 ) 1672 3600 RRSIG SOA 5 1 3600 20040509183619 ( 1673 20040409183619 38519 example. 1674 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 1675 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 1676 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 1677 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 1678 jV7j86HyQgM5e7+miRAz8V01b0I= ) 1679 3600 NS ns1.example. 1680 3600 NS ns2.example. 1681 3600 RRSIG NS 5 1 3600 20040509183619 ( 1682 20040409183619 38519 example. 1683 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd 1684 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 1685 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 1686 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 1687 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 1688 3600 MX 1 xx.example. 1689 3600 RRSIG MX 5 1 3600 20040509183619 ( 1690 20040409183619 38519 example. 1691 HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB 1692 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE 1693 VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO 1694 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM 1695 W6OISukd1EQt7a0kygkg+PEDxdI= ) 1696 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 1697 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 1698 20040409183619 38519 example. 1699 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm 1700 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V 1701 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW 1702 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm 1703 jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 1704 3600 DNSKEY 256 3 5 ( 1705 AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV 1706 rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e 1707 k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo 1708 vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI 1709 ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== 1710 ) 1711 3600 DNSKEY 257 3 5 ( 1712 AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl 1713 LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ 1714 syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP 1715 RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT 1716 Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== 1717 ) 1718 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 1719 20040409183619 9465 example. 1720 ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ 1721 xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ 1722 XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 1723 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY 1724 NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) 1725 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 1726 20040409183619 38519 example. 1727 eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z 1728 DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri 1729 bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp 1730 eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk 1731 7z5OXogYVaFzHKillDt3HRxHIZM= ) 1732 a.example. 3600 IN NS ns1.a.example. 1733 3600 IN NS ns2.a.example. 1734 3600 DS 57855 5 1 ( 1735 B6DCD485719ADCA18E5F3D48A2331627FDD3 1736 636B ) 1737 3600 RRSIG DS 5 2 3600 20040509183619 ( 1738 20040409183619 38519 example. 1739 oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ 1740 oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH 1741 kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD 1742 EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ 1743 Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 1744 3600 NSEC ai.example. NS DS RRSIG NSEC 1745 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 1746 20040409183619 38519 example. 1747 cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba 1748 U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 1749 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I 1750 BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g 1751 sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) 1752 ns1.a.example. 3600 IN A 192.0.2.5 1753 ns2.a.example. 3600 IN A 192.0.2.6 1754 ai.example. 3600 IN A 192.0.2.9 1755 3600 RRSIG A 5 2 3600 20040509183619 ( 1756 20040409183619 38519 example. 1758 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B 1759 ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd 1760 hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u 1761 ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 1762 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) 1763 3600 HINFO "KLH-10" "ITS" 1764 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 1765 20040409183619 38519 example. 1766 Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l 1767 e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh 1768 ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 1769 AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw 1770 FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) 1771 3600 AAAA 2001:db8::f00:baa9 1772 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 1773 20040409183619 38519 example. 1774 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK 1775 kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1776 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T 1777 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 1778 sZM6QjBBLmukH30+w1z3h8PUP2o= ) 1779 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC 1780 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 1781 20040409183619 38519 example. 1782 QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG 1783 CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p 1784 P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN 1785 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL 1786 AhS+JOVfDI/79QtyTI0SaDWcg8U= ) 1787 b.example. 3600 IN NS ns1.b.example. 1788 3600 IN NS ns2.b.example. 1789 3600 NSEC ns1.example. NS RRSIG NSEC 1790 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 1791 20040409183619 38519 example. 1792 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 1793 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS 1794 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 1795 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ 1796 vhRXgWT7OuFXldoCG6TfVFMs9xE= ) 1797 ns1.b.example. 3600 IN A 192.0.2.7 1798 ns2.b.example. 3600 IN A 192.0.2.8 1799 ns1.example. 3600 IN A 192.0.2.1 1800 3600 RRSIG A 5 2 3600 20040509183619 ( 1801 20040409183619 38519 example. 1802 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 1803 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 1804 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ 1805 +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK 1806 v/iVXSYC0b7mPSU+EOlknFpVECs= ) 1807 3600 NSEC ns2.example. A RRSIG NSEC 1808 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 1809 20040409183619 38519 example. 1810 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1811 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB 1812 jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq 1813 ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 1814 IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) 1815 ns2.example. 3600 IN A 192.0.2.2 1816 3600 RRSIG A 5 2 3600 20040509183619 ( 1817 20040409183619 38519 example. 1818 V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq 1819 Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu 1820 yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 1821 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq 1822 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) 1823 3600 NSEC *.w.example. A RRSIG NSEC 1824 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 1825 20040409183619 38519 example. 1826 N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE 1827 VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb 1828 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH 1829 l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw 1830 Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) 1831 *.w.example. 3600 IN MX 1 ai.example. 1832 3600 RRSIG MX 5 2 3600 20040509183619 ( 1833 20040409183619 38519 example. 1834 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 1835 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc 1836 tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X 1837 TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 1838 4kX18MMR34i8lC36SR5xBni8vHI= ) 1839 3600 NSEC x.w.example. MX RRSIG NSEC 1840 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 1841 20040409183619 38519 example. 1842 r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 1843 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 1844 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 1845 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 1846 s1InQ2UoIv6tJEaaKkP701j8OLA= ) 1847 x.w.example. 3600 IN MX 1 xx.example. 1848 3600 RRSIG MX 5 3 3600 20040509183619 ( 1849 20040409183619 38519 example. 1850 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 1851 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP 1852 H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I 1853 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 1854 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) 1855 3600 NSEC x.y.w.example. MX RRSIG NSEC 1856 3600 RRSIG NSEC 5 3 3600 20040509183619 ( 1857 20040409183619 38519 example. 1858 aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK 1859 vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E 1860 mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI 1861 NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e 1862 IjgiM8PXkBQtxPq37wDKALkyn7Q= ) 1863 x.y.w.example. 3600 IN MX 1 xx.example. 1864 3600 RRSIG MX 5 4 3600 20040509183619 ( 1865 20040409183619 38519 example. 1866 k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia 1867 t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj 1868 q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq 1869 GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb 1870 +gLcMZBnHJ326nb/TOOmrqNmQQE= ) 1871 3600 NSEC xx.example. MX RRSIG NSEC 1872 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 1873 20040409183619 38519 example. 1874 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp 1875 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg 1876 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX 1877 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr 1878 QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) 1879 xx.example. 3600 IN A 192.0.2.10 1880 3600 RRSIG A 5 2 3600 20040509183619 ( 1881 20040409183619 38519 example. 1882 kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 1883 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 1884 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y 1885 VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx 1886 kbIDV6GPPSZVusnZU6OMgdgzHV4= ) 1887 3600 HINFO "KLH-10" "TOPS-20" 1888 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 1889 20040409183619 38519 example. 1890 GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 1891 t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq 1892 BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 1893 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ 1894 RgNvuwbioFSEuv2pNlkq0goYxNY= ) 1895 3600 AAAA 2001:db8::f00:baaa 1896 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 1897 20040409183619 38519 example. 1898 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C 1899 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z 1900 ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr 1901 U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ 1902 xS9cL2QgW7FChw16mzlkH6/vsfs= ) 1903 3600 NSEC example. A HINFO AAAA RRSIG NSEC 1904 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 1905 20040409183619 38519 example. 1906 ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY 1907 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k 1908 mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi 1909 asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W 1910 GghLahumFIpg4MO3LS/prgzVVWo= ) 1912 The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA 1913 Flags indicate that each of these DNSKEY RRs is a zone key. One of 1914 these DNSKEY RRs also has the SEP flag set and has been used to sign 1915 the apex DNSKEY RRset; this is the key which should be hashed to 1916 generate a DS record to be inserted into the parent zone. The other 1917 DNSKEY is used to sign all the other RRsets in the zone. 1919 The zone includes a wildcard entry "*.w.example". Note that the name 1920 "*.w.example" is used in constructing NSEC chains, and that the RRSIG 1921 covering the "*.w.example" MX RRset has a label count of 2. 1923 The zone also includes two delegations. The delegation to 1924 "b.example" includes an NS RRset, glue address records, and an NSEC 1925 RR; note that only the NSEC RRset is signed. The delegation to 1926 "a.example" provides a DS RR; note that only the NSEC and DS RRsets 1927 are signed. 1929 Appendix B. Example Responses 1931 The examples in this section show response messages using the signed 1932 zone example in Appendix A. 1934 B.1 Answer 1936 A successful query to an authoritative server. 1938 ;; Header: QR AA DO RCODE=0 1939 ;; 1940 ;; Question 1941 x.w.example. IN MX 1943 ;; Answer 1944 x.w.example. 3600 IN MX 1 xx.example. 1945 x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( 1946 20040409183619 38519 example. 1947 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 1948 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP 1949 H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I 1950 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 1951 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) 1953 ;; Authority 1954 example. 3600 NS ns1.example. 1955 example. 3600 NS ns2.example. 1956 example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 1957 20040409183619 38519 example. 1958 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd 1959 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 1960 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 1961 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 1962 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 1964 ;; Additional 1965 xx.example. 3600 IN A 192.0.2.10 1966 xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 1967 20040409183619 38519 example. 1968 kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 1969 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 1970 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y 1971 VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx 1972 kbIDV6GPPSZVusnZU6OMgdgzHV4= ) 1973 xx.example. 3600 AAAA 2001:db8::f00:baaa 1974 xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 1975 20040409183619 38519 example. 1976 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C 1977 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z 1978 ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr 1979 U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ 1980 xS9cL2QgW7FChw16mzlkH6/vsfs= ) 1981 ns1.example. 3600 IN A 192.0.2.1 1982 ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 1983 20040409183619 38519 example. 1984 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 1985 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 1986 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ 1987 +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK 1988 v/iVXSYC0b7mPSU+EOlknFpVECs= ) 1989 ns2.example. 3600 IN A 192.0.2.2 1990 ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 1991 20040409183619 38519 example. 1992 V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq 1993 Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu 1994 yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 1995 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq 1996 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) 1998 B.2 Name Error 2000 An authoritative name error. The NSEC RRs prove that the name does 2001 not exist and that no covering wildcard exists. 2003 ;; Header: QR AA DO RCODE=3 2004 ;; 2005 ;; Question 2006 ml.example. IN A 2008 ;; Answer 2009 ;; (empty) 2011 ;; Authority 2012 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 2013 1081539377 2014 3600 2015 300 2016 3600000 2017 3600 2018 ) 2019 example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 2020 20040409183619 38519 example. 2021 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 2022 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 2023 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 2024 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 2025 jV7j86HyQgM5e7+miRAz8V01b0I= ) 2026 b.example. 3600 NSEC ns1.example. NS RRSIG NSEC 2027 b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2028 20040409183619 38519 example. 2029 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 2030 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS 2031 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 2032 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ 2033 vhRXgWT7OuFXldoCG6TfVFMs9xE= ) 2034 example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 2035 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 2036 20040409183619 38519 example. 2037 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm 2038 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V 2039 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW 2040 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm 2041 jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 2043 ;; Additional 2044 ;; (empty) 2046 B.3 No Data Error 2048 A "no data" response. The NSEC RR proves that the name exists and 2049 that the requested RR type does not. 2051 ;; Header: QR AA DO RCODE=0 2052 ;; 2053 ;; Question 2054 ns1.example. IN MX 2056 ;; Answer 2057 ;; (empty) 2059 ;; Authority 2060 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 2061 1081539377 2062 3600 2063 300 2064 3600000 2065 3600 2066 ) 2067 example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 2068 20040409183619 38519 example. 2069 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 2070 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 2071 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 2072 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 2073 jV7j86HyQgM5e7+miRAz8V01b0I= ) 2074 ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC 2075 ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2076 20040409183619 38519 example. 2077 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 2078 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB 2079 jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq 2080 ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 2081 IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) 2083 ;; Additional 2084 ;; (empty) 2086 B.4 Referral to Signed Zone 2088 Referral to a signed zone. The DS RR contains the data which the 2089 resolver will need to validate the corresponding DNSKEY RR in the 2090 child zone's apex. 2092 ;; Header: QR DO RCODE=0 2093 ;; 2094 ;; Question 2095 mc.a.example. IN MX 2097 ;; Answer 2098 ;; (empty) 2100 ;; Authority 2101 a.example. 3600 IN NS ns1.a.example. 2102 a.example. 3600 IN NS ns2.a.example. 2103 a.example. 3600 DS 57855 5 1 ( 2104 B6DCD485719ADCA18E5F3D48A2331627FDD3 2105 636B ) 2106 a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( 2107 20040409183619 38519 example. 2108 oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ 2109 oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH 2110 kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD 2111 EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ 2112 Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 2114 ;; Additional 2115 ns1.a.example. 3600 IN A 192.0.2.5 2116 ns2.a.example. 3600 IN A 192.0.2.6 2118 B.5 Referral to Unsigned Zone 2120 Referral to an unsigned zone. The NSEC RR proves that no DS RR for 2121 this delegation exists in the parent zone. 2123 ;; Header: QR DO RCODE=0 2124 ;; 2125 ;; Question 2126 mc.b.example. IN MX 2128 ;; Answer 2129 ;; (empty) 2131 ;; Authority 2132 b.example. 3600 IN NS ns1.b.example. 2133 b.example. 3600 IN NS ns2.b.example. 2134 b.example. 3600 NSEC ns1.example. NS RRSIG NSEC 2135 b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2136 20040409183619 38519 example. 2137 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 2138 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS 2139 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 2140 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ 2141 vhRXgWT7OuFXldoCG6TfVFMs9xE= ) 2143 ;; Additional 2144 ns1.b.example. 3600 IN A 192.0.2.7 2145 ns2.b.example. 3600 IN A 192.0.2.8 2147 B.6 Wildcard Expansion 2149 A successful query which was answered via wildcard expansion. The 2150 label count in the answer's RRSIG RR indicates that a wildcard RRset 2151 was expanded to produce this response, and the NSEC RR proves that no 2152 closer match exists in the zone. 2154 ;; Header: QR AA DO RCODE=0 2155 ;; 2156 ;; Question 2157 a.z.w.example. IN MX 2159 ;; Answer 2160 a.z.w.example. 3600 IN MX 1 ai.example. 2161 a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 2162 20040409183619 38519 example. 2163 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 2164 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc 2165 tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X 2166 TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 2167 4kX18MMR34i8lC36SR5xBni8vHI= ) 2169 ;; Authority 2170 example. 3600 NS ns1.example. 2171 example. 3600 NS ns2.example. 2172 example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 2173 20040409183619 38519 example. 2174 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd 2175 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 2176 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 2177 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 2178 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 2179 x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC 2180 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 2181 20040409183619 38519 example. 2182 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp 2183 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg 2184 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX 2185 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr 2186 QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) 2188 ;; Additional 2189 ai.example. 3600 IN A 192.0.2.9 2190 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 2191 20040409183619 38519 example. 2192 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B 2193 ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd 2194 hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u 2195 ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 2196 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) 2197 ai.example. 3600 AAAA 2001:db8::f00:baa9 2198 ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 2199 20040409183619 38519 example. 2200 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK 2201 kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 2202 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T 2203 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 2204 sZM6QjBBLmukH30+w1z3h8PUP2o= ) 2206 B.7 Wildcard No Data Error 2208 A "no data" response for a name covered by a wildcard. The NSEC RRs 2209 prove that the matching wildcard name does not have any RRs of the 2210 requested type and that no closer match exists in the zone. 2212 ;; Header: QR AA DO RCODE=0 2213 ;; 2214 ;; Question 2215 a.z.w.example. IN AAAA 2216 ;; Answer 2217 ;; (empty) 2219 ;; Authority 2220 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 2221 1081539377 2222 3600 2223 300 2224 3600000 2225 3600 2226 ) 2227 example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 2228 20040409183619 38519 example. 2229 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 2230 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 2231 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 2232 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 2233 jV7j86HyQgM5e7+miRAz8V01b0I= ) 2234 x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC 2235 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 2236 20040409183619 38519 example. 2237 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp 2238 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg 2239 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX 2240 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr 2241 QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) 2242 *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC 2243 *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2244 20040409183619 38519 example. 2245 r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 2246 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 2247 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 2248 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 2249 s1InQ2UoIv6tJEaaKkP701j8OLA= ) 2251 ;; Additional 2252 ;; (empty) 2254 B.8 DS Child Zone No Data Error 2256 A "no data" response for a QTYPE=DS query which was mistakenly sent 2257 to a name server for the child zone. 2259 ;; Header: QR AA DO RCODE=0 2260 ;; 2261 ;; Question 2262 example. IN DS 2264 ;; Answer 2265 ;; (empty) 2267 ;; Authority 2268 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 2269 1081539377 2270 3600 2271 300 2272 3600000 2273 3600 2274 ) 2275 example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 2276 20040409183619 38519 example. 2277 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 2278 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 2279 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 2280 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 2281 jV7j86HyQgM5e7+miRAz8V01b0I= ) 2282 example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 2283 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 2284 20040409183619 38519 example. 2285 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm 2286 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V 2287 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW 2288 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm 2289 jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 2291 ;; Additional 2292 ;; (empty) 2294 Appendix C. Authentication Examples 2296 The examples in this section show how the response messages in 2297 Appendix B are authenticated. 2299 C.1 Authenticating An Answer 2301 The query in Appendix B.1 returned an MX RRset for "x.w.example.com". 2302 The corresponding RRSIG indicates the MX RRset was signed by an 2303 "example" DNSKEY with algorithm 5 and key tag 38519. The resolver 2304 needs the corresponding DNSKEY RR in order to authenticate this 2305 answer. The discussion below describes how a resolver might obtain 2306 this DNSKEY RR. 2308 The RRSIG indicates the original TTL of the MX RRset was 3600 and, 2309 for the purpose of authentication, the current TTL is replaced by 2310 3600. The RRSIG labels field value of 3 indicates the answer was not 2311 the result of wildcard expansion. The "x.w.example.com" MX RRset is 2312 placed in canonical form and, assuming the current time falls between 2313 the signature inception and expiration dates, the signature is 2314 authenticated. 2316 C.1.1 Authenticating the example DNSKEY RR 2318 This example shows the logical authentication process that starts 2319 from the a configured root DNSKEY (or DS RR) and moves down the tree 2320 to authenticate the desired "example" DNSKEY RR. Note the logical 2321 order is presented for clarity and an implementation may choose to 2322 construct the authentication as referrals are received or may choose 2323 to construct the authentication chain only after all RRsets have been 2324 obtained, or in any other combination it sees fit. The example here 2325 demonstrates only the logical process and does not dictate any 2326 implementation rules. 2328 We assume the resolver starts with an configured DNSKEY RR for the 2329 root zone (or a configured DS RR for the root zone). The resolver 2330 checks this configured DNSKEY RR is present in the root DNSKEY RRset 2331 (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this 2332 DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime 2333 is valid. If all these conditions are met, all keys in the DNSKEY 2334 RRset are considered authenticated. The resolver then uses one (or 2335 more) of the root DNSKEY RRs to authenticate the "example" DS RRset. 2336 Note the resolver may need to query the root zone to obtain the root 2337 DNSKEY RRset or "example" DS RRset. 2339 Once the DS RRset has been authenticated using the root DNSKEY, the 2340 resolver checks the "example" DNSKEY RRset for some "example" DNSKEY 2341 RR that matches one of the authenticated "example" DS RRs. If such a 2342 matching "example" DNSKEY is found, the resolver checks this DNSKEY 2343 RR has signed the "example" DNSKEY RRset and the signature lifetime 2344 is valid. If all these conditions are met, all keys in the "example" 2345 DNSKEY RRset are considered authenticated. 2347 Finally the resolver checks that some DNSKEY RR in the "example" 2348 DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This 2349 DNSKEY is used to authenticated the RRSIG included in the response. 2350 If multiple "example" DNSKEY RRs match this algorithm and key tag, 2351 then each DNSKEY RR is tried and the answer is authenticated if any 2352 of the matching DNSKEY RRs validates the signature as described 2353 above. 2355 C.2 Name Error 2357 The query in Appendix B.2 returned NSEC RRs that prove the requested 2358 data does not exist and no wildcard applies. The negative reply is 2359 authenticated by verifying both NSEC RRs. The NSEC RRs are 2360 authenticated in a manner identical to that of the MX RRset discussed 2361 above. 2363 C.3 No Data Error 2365 The query in Appendix B.3 returned an NSEC RR that proves the 2366 requested name exists, but the requested RR type does not exist. The 2367 negative reply is authenticated by verifying the NSEC RR. The NSEC 2368 RR is authenticated in a manner identical to that of the MX RRset 2369 discussed above. 2371 C.4 Referral to Signed Zone 2373 The query in Appendix B.4 returned a referral to the signed 2374 "a.example." zone. The DS RR is authenticated in a manner identical 2375 to that of the MX RRset discussed above. This DS RR is used to 2376 authenticate the "a.example" DNSKEY RRset. 2378 Once the "a.example" DS RRset has been authenticated using the 2379 "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset 2380 for some "a.example" DNSKEY RR that matches the DS RR. If such a 2381 matching "a.example" DNSKEY is found, the resolver checks this DNSKEY 2382 RR has signed the "a.example" DNSKEY RRset and the signature lifetime 2383 is valid. If all these conditions are met, all keys in the 2384 "a.example" DNSKEY RRset are considered authenticated. 2386 C.5 Referral to Unsigned Zone 2388 The query in Appendix B.5 returned a referral to an unsigned 2389 "b.example." zone. The NSEC proves that no authentication leads from 2390 "example" to "b.example" and the NSEC RR is authenticated in a manner 2391 identical to that of the MX RRset discussed above. 2393 C.6 Wildcard Expansion 2395 The query in Appendix B.6 returned an answer that was produced as a 2396 result of wildcard expansion. The answer section contains a wildcard 2397 RRset expanded as in a traditional DNS response and the corresponding 2398 RRSIG indicates that the expanded wildcard MX RRset was signed by an 2399 "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG 2400 indicates the original TTL of the MX RRset was 3600 and, for the 2401 purpose of authentication, the current TTL is replaced by 3600. The 2402 RRSIG labels field value of 2 indicates the answer the result of 2403 wildcard expansion since the "a.z.w.example" name contains 4 labels. 2404 The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset 2405 is placed in canonical form and, assuming the current time falls 2406 between the signature inception and expiration dates, the signature 2407 is authenticated. 2409 The NSEC proves that no closer match (exact or closer wildcard) could 2410 have been used to answer this query and the NSEC RR must also be 2411 authenticated before the answer is considered valid. 2413 C.7 Wildcard No Data Error 2415 The query in Appendix B.7 returned NSEC RRs that prove the requested 2416 data does not exist and no wildcard applies. The negative reply is 2417 authenticated by verifying both NSEC RRs. 2419 C.8 DS Child Zone No Data Error 2421 The query in Appendix B.8 returned NSEC RRs that shows the requested 2422 was answered by a child server ("example" server). The NSEC RR 2423 indicates the presence of an SOA RR, showing the answer is from the 2424 child . Queries for the "example" DS RRset should be sent to the 2425 parent servers ("root" servers). 2427 Intellectual Property Statement 2429 The IETF takes no position regarding the validity or scope of any 2430 Intellectual Property Rights or other rights that might be claimed to 2431 pertain to the implementation or use of the technology described in 2432 this document or the extent to which any license under such rights 2433 might or might not be available; nor does it represent that it has 2434 made any independent effort to identify any such rights. Information 2435 on the procedures with respect to rights in RFC documents can be 2436 found in BCP 78 and BCP 79. 2438 Copies of IPR disclosures made to the IETF Secretariat and any 2439 assurances of licenses to be made available, or the result of an 2440 attempt made to obtain a general license or permission for the use of 2441 such proprietary rights by implementers or users of this 2442 specification can be obtained from the IETF on-line IPR repository at 2443 http://www.ietf.org/ipr. 2445 The IETF invites any interested party to bring to its attention any 2446 copyrights, patents or patent applications, or other proprietary 2447 rights that may cover technology that may be required to implement 2448 this standard. Please address the information to the IETF at 2449 ietf-ipr@ietf.org. 2451 Disclaimer of Validity 2453 This document and the information contained herein are provided on an 2454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2456 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2457 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2458 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2461 Copyright Statement 2463 Copyright (C) The Internet Society (2004). This document is subject 2464 to the rights, licenses and restrictions contained in BCP 78, and 2465 except as set forth therein, the authors retain all their rights. 2467 Acknowledgment 2469 Funding for the RFC Editor function is currently provided by the 2470 Internet Society.