1 Network Working Group R. Arends 2 Request for Comments: 4035 Telematica Instituut 3 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein 4 3755, 3757, 3845 ISC
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
RFC6840, "Clarifications and Implementation Notes for DNSSEC", updates RFC 4035 in many places throughout the document.
5 Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson 6 3007, 3597, 3226 VeriSign 7 Category: Standards Track D. Massey 8 Colorado State University 9 S. Rose 10 NIST 11 March 2005 12 13 14 Protocol Modifications for the DNS Security Extensions 15 16 Status of This Memo 17 18 This document specifies an Internet standards track protocol for the 19 Internet community, and requests discussion and suggestions for 20 improvements. Please refer to the current edition of the "Internet 21 Official Protocol Standards" (STD 1) for the standardization state 22 and status of this protocol. Distribution of this memo is unlimited. 23 24 Copyright Notice 25 26 Copyright (C) The Internet Society (2005). 27 28 Abstract 29 30 This document is part of a family of documents that describe the DNS 31 Security Extensions (DNSSEC). The DNS Security Extensions are a 32 collection of new resource records and protocol modifications that 33 add data origin authentication and data integrity to the DNS. This 34 document describes the DNSSEC protocol modifications. This document 35 defines the concept of a signed zone, along with the requirements for 36 serving and resolving by using DNSSEC. These techniques allow a 37 security-aware resolver to authenticate both DNS resource records and 38 authoritative DNS error indications. 39 40 This document obsoletes RFC 2535 and incorporates changes from all 41 updates to RFC 2535. 42 43 44 45 46 47 48 49 50 51 52 Arends, et al. Standards Track [Page 1] 53 RFC 4035 DNSSEC Protocol Modifications March 2005 54 55 56 Table of Contents 57 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Background and Related Documents . . . . . . . . . . . . 4 60 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 61 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5 63 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5 64 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6 65 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7 66 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7 67 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8 68 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8 69 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9 71 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10 72 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11 73 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11 74 3.1.4. Including DS RRs in a Response . . . . . . . . . 14 75 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15 76 3.1.6. The AD and CD Bits in an Authoritative Response. 16 77 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17 78 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17 79 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17 80 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18 81 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19 82 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19 84 4.2. Signature Verification Support . . . . . . . . . . . . . 19 85 4.3. Determining Security Status of Data . . . . . . . . . . 20 86 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21 87 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21 88 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22 89 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22 90 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23 91 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23 92 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24 93 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24 94 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24 95 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 96 5.1. Special Considerations for Islands of Security . . . . . 26 97 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26 98 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28 99 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28 100 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29 101 5.3.3. Checking the Signature . . . . . . . . . . . . . 31 102 5.3.4. Authenticating a Wildcard Expanded RRset 103 Positive Response. . . . . . . . . . . . . . . . 32 104 105 106 107 Arends, et al. Standards Track [Page 2] 108 RFC 4035 DNSSEC Protocol Modifications March 2005 109 110 111 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32 112 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33 113 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 116 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 117 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 118 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 119 9.2. Informative References . . . . . . . . . . . . . . . . . 35 120 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36 121 B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41 122 B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41 123 B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43 124 B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44 125 B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44 126 B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45 127 B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46 128 B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47 129 B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48 130 C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49 131 C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49 132 C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49 133 C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50 134 C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50 135 C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50 136 C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51 137 C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51 138 C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51 139 C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 141 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 142 143 1. Introduction 144 145 The DNS Security Extensions (DNSSEC) are a collection of new resource 146 records and protocol modifications that add data origin 147 authentication and data integrity to the DNS. This document defines 148 the DNSSEC protocol modifications. Section 2 of this document 149 defines the concept of a signed zone and lists the requirements for 150 zone signing. Section 3 describes the modifications to authoritative 151 name server behavior necessary for handling signed zones. Section 4 152 describes the behavior of entities that include security-aware 153 resolver functions. Finally, Section 5 defines how to use DNSSEC RRs 154 to authenticate a response. 155 156 157 158 159 160 161 162 Arends, et al. Standards Track [Page 3] 163 RFC 4035 DNSSEC Protocol Modifications March 2005 164 165 166 1.1. Background and Related Documents 167 168 This document is part of a family of documents defining DNSSEC that 169 should be read together as a set. 170 171 [RFC4033] contains an introduction to DNSSEC and definitions of 172 common terms; the reader is assumed to be familiar with this 173 document. [RFC4033] also contains a list of other documents updated 174 by and obsoleted by this document set. 175 176 [RFC4034] defines the DNSSEC resource records. 177 178 The reader is also assumed to be familiar with the basic DNS concepts 179 described in [RFC1034], [RFC1035], and the subsequent documents that 180 update them; particularly, [RFC2181] and [RFC2308]. 181 182 This document defines the DNSSEC protocol operations. 183 184 1.2. Reserved Words 185 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 189 190 2. Zone Signing 191 192 DNSSEC introduces the concept of signed zones. A signed zone 193 includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), 194 Next Secure (NSEC), and (optionally) Delegation Signer (DS) records 195 according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4, 196 respectively. A zone that does not include these records according 197 to the rules in this section is an unsigned zone. 198 199 DNSSEC requires a change to the definition of the CNAME resource 200 record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG 201 and NSEC RRs to appear at the same owner name as does a CNAME RR. 202 203 DNSSEC specifies the placement of two new RR types, NSEC and DS, 204 which can be placed at the parental side of a zone cut (that is, at a 205 delegation point). This is an exception to the general prohibition 206 against putting data in the parent zone at a zone cut. Section 2.6 207 describes this change. 208 209 210 211 212 213 214 215 216 217 Arends, et al. Standards Track [Page 4] 218 RFC 4035 DNSSEC Protocol Modifications March 2005 219 220 221 2.1. Including DNSKEY RRs in a Zone 222 223 To sign a zone, the zone's administrator generates one or more 224 public/private key pairs and uses the private key(s) to sign 225 authoritative RRsets in the zone. For each private key used to 226 create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR 227 containing the corresponding public key. A zone key DNSKEY RR MUST 228 have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 229 of [RFC4034]). Public keys associated with other DNS operations MAY 230 be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT 231 be used to verify RRSIGs. 232 233 If the zone administrator intends a signed zone to be usable other 234 than as an island of security, the zone apex MUST contain at least 235 one DNSKEY RR to act as a secure entry point into the zone. This 236 secure entry point could then be used as the target of a secure 237 delegation via a corresponding DS RR in the parent zone (see 238 [RFC4034]). 239 240 2.2. Including RRSIG RRs in a Zone 241 242 For each authoritative RRset in a signed zone, there MUST be at least 243 one RRSIG record that meets the following requirements: 244 245 o The RRSIG owner name is equal to the RRset owner name. 246 247 o The RRSIG class is equal to the RRset class. 248 249 o The RRSIG Type Covered field is equal to the RRset type. 250 251 o The RRSIG Original TTL field is equal to the TTL of the RRset. 252 253 o The RRSIG RR's TTL is equal to the TTL of the RRset. 254 255 o The RRSIG Labels field is equal to the number of labels in the 256 RRset owner name, not counting the null root label and not 257 counting the leftmost label if it is a wildcard. 258 259 o The RRSIG Signer's Name field is equal to the name of the zone 260 containing the RRset. 261 262 o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a 263 zone key DNSKEY record at the zone apex. 264 265 The process for constructing the RRSIG RR for a given RRset is 266 described in [RFC4034]. An RRset MAY have multiple RRSIG RRs 267 associated with it. Note that as RRSIG RRs are closely tied to the 268 RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS 269 270 271 272 Arends, et al. Standards Track [Page 5] 273 RFC 4035 DNSSEC Protocol Modifications March 2005 274 275 276 RR types, do not form RRsets. In particular, the TTL values among 277 RRSIG RRs with a common owner name do not follow the RRset rules 278 described in [RFC2181]. 279 280 An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would 281 add no value and would create an infinite loop in the signing 282 process. 283 284 The NS RRset that appears at the zone apex name MUST be signed, but 285 the NS RRsets that appear at delegation points (that is, the NS 286 RRsets in the parent zone that delegate the name to the child zone's 287 name servers) MUST NOT be signed. Glue address RRsets associated 288 with delegations MUST NOT be signed. 289
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson 3007, 3597, 3226 VeriSign
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007,3597, 3226 VeriSign
290 There MUST be an RRSIG for each RRset using at least one DNSKEY of 291 each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset 292 itself MUST be signed by each algorithm appearing in the DS RRset 293 located at the delegating parent (if any). 294
Section 5.11 of RFC6840 says:
The last paragraph of Section 2.2 of [RFC4035] includes rules describing which algorithms must be used to sign a zone. Since these rules have been confusing, they are restated using different language here: The DS RRset and DNSKEY RRset are used to signal which algorithms are used to sign a zone. The presence of an algorithm in either a zone's DS or DNSKEY RRset signals that that algorithm is used to sign the entire zone. A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset. It is possible to add algorithms at the DNSKEY that aren't in the DS record, but not vice versa. If more than one key of the same algorithm is in the DNSKEY RRset, it is sufficient to sign each RRset with any subset of these DNSKEYs. It is acceptable to sign some RRsets with one subset of keys (or key) and other RRsets with a different subset, so long as at least one DNSKEY of each algorithm is used to sign each RRset. Likewise, if there are DS records for multiple keys of the same algorithm, any subset of those may appear in the DNSKEY RRset. This requirement applies to servers, not validators. Validators SHOULD accept any single valid path. They SHOULD NOT insist that all algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work. A validator MAY have a configuration option to perform a signature completeness test to support troubleshooting.
295 2.3. Including NSEC RRs in a Zone 296 297 Each owner name in the zone that has authoritative data or a 298 delegation point NS RRset MUST have an NSEC resource record. The 299 format of NSEC RRs and the process for constructing the NSEC RR for a 300 given name is described in [RFC4034]. 301
Section 3 of RFC4470 says:
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set and SHOULD NOT have any other bits set. This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at names that did not exist before the zone was signed.
302 The TTL value for any NSEC RR SHOULD be the same as the minimum TTL 303 value field in the zone SOA RR. 304 305 An NSEC record (and its associated RRSIG RRset) MUST NOT be the only 306 RRset at any particular owner name. That is, the signing process 307 MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not 308 the owner name of any RRset before the zone was signed. The main 309 reasons for this are a desire for namespace consistency between 310 signed and unsigned versions of the same zone and a desire to reduce 311 the risk of response inconsistency in security oblivious recursive 312 name servers. 313 314 The type bitmap of every NSEC resource record in a signed zone MUST 315 indicate the presence of both the NSEC record itself and its 316 corresponding RRSIG record. 317 318 The difference between the set of owner names that require RRSIG 319 records and the set of owner names that require NSEC records is 320 subtle and worth highlighting. RRSIG records are present at the 321 owner names of all authoritative RRsets. NSEC records are present at 322 the owner names of all names for which the signed zone is 323 authoritative and also at the owner names of delegations from the 324 325 326 327 Arends, et al. Standards Track [Page 6] 328 RFC 4035 DNSSEC Protocol Modifications March 2005 329 330 331 signed zone to its children. Neither NSEC nor RRSIG records are 332 present (in the parent zone) at the owner names of glue address 333 RRsets. Note, however, that this distinction is for the most part 334 visible only during the zone signing process, as NSEC RRsets are 335 authoritative data and are therefore signed. Thus, any owner name 336 that has an NSEC RRset will have RRSIG RRs as well in the signed 337 zone. 338 339 The bitmap for the NSEC RR at a delegation point requires special 340 attention. Bits corresponding to the delegation NS RRset and any 341 RRsets for which the parent zone has authoritative data MUST be set; 342 bits corresponding to any non-NS RRset for which the parent is not 343 authoritative MUST be clear. 344 345 2.4. Including DS RRs in a Zone 346 347 The DS resource record establishes authentication chains between DNS 348 zones. A DS RRset SHOULD be present at a delegation point when the 349 child zone is signed. The DS RRset MAY contain multiple records, 350 each referencing a public key in the child zone used to verify the 351 RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS 352 RRsets MUST NOT appear at a zone's apex. 353 354 A DS RR SHOULD point to a DNSKEY RR that is present in the child's 355 apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed 356 by the corresponding private key. DS RRs that fail to meet these 357 conditions are not useful for validation, but because the DS RR and 358 its corresponding DNSKEY RR are in different zones, and because the 359 DNS is only loosely consistent, temporary mismatches can occur. 360 361 The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset 362 (that is, the NS RRset from the same zone containing the DS RRset). 363 364 Construction of a DS RR requires knowledge of the corresponding 365 DNSKEY RR in the child zone, which implies communication between the 366 child and parent zones. This communication is an operational matter 367 not covered by this document. 368 369 2.5. Changes to the CNAME Resource Record 370 371 If a CNAME RRset is present at a name in a signed zone, appropriate 372 RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that 373 name for secure dynamic update purposes is also allowed ([RFC3007]). 374 Other types MUST NOT be present at that name. 375 376 This is a modification to the original CNAME definition given in 377 [RFC1034]. The original definition of the CNAME RR did not allow any 378 other types to coexist with a CNAME record, but a signed zone 379 380 381 382 Arends, et al. Standards Track [Page 7] 383 RFC 4035 DNSSEC Protocol Modifications March 2005 384 385 386 requires NSEC and RRSIG RRs for every authoritative name. To resolve 387 this conflict, this specification modifies the definition of the 388 CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. 389 390 2.6. DNSSEC RR Types Appearing at Zone Cuts 391 392 DNSSEC introduced two new RR types that are unusual in that they can 393 appear at the parental side of a zone cut. At the parental side of a 394 zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at 395 the owner name. A DS RR could also be present if the zone being 396 delegated is signed and seeks to have a chain of authentication to 397 the parent zone. This is an exception to the original DNS 398 specification ([RFC1034]), which states that only NS RRsets could 399 appear at the parental side of a zone cut. 400 401 This specification updates the original DNS specification to allow 402 NSEC and DS RR types at the parent side of a zone cut. These RRsets 403 are authoritative for the parent when they appear at the parent side 404 of a zone cut. 405 406 2.7. Example of a Secure Zone 407 408 Appendix A shows a complete example of a small signed zone. 409 410 3. Serving 411 412 This section describes the behavior of entities that include 413 security-aware name server functions. In many cases such functions 414 will be part of a security-aware recursive name server, but a 415 security-aware authoritative name server has some of the same 416 requirements. Functions specific to security-aware recursive name 417 servers are described in Section 3.2; functions specific to 418 authoritative servers are described in Section 3.1. 419 420 In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" 421 are as used in [RFC1034]. 422 423 A security-aware name server MUST support the EDNS0 ([RFC2671]) 424 message size extension, MUST support a message size of at least 1220 425 octets, and SHOULD support a message size of 4000 octets. As IPv6 426 packets can only be fragmented by the source host, a security aware 427 name server SHOULD take steps to ensure that UDP datagrams it 428 transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 429 MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], 430 and [RFC3226] for further discussion of packet size and fragmentation 431 issues. 432 433 434 435 436 437 Arends, et al. Standards Track [Page 8] 438 RFC 4035 DNSSEC Protocol Modifications March 2005 439 440 441 A security-aware name server that receives a DNS query that does not 442 include the EDNS OPT pseudo-RR or that has the DO bit clear MUST 443 treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and 444 MUST NOT perform any of the additional processing described below. 445 Because the DS RR type has the peculiar property of only existing in 446 the parent zone at delegation points, DS RRs always require some 447 special processing, as described in Section 126.96.36.199. 448 449 Security aware name servers that receive explicit queries for 450 security RR types that match the content of more than one zone that 451 it serves (for example, NSEC and RRSIG RRs above and below a 452 delegation point where the server is authoritative for both zones) 453 should behave self-consistently. As long as the response is always 454 consistent for each query to the name server, the name server MAY 455 return one of the following: 456 457 o The above-delegation RRsets. 458 o The below-delegation RRsets. 459 o Both above and below-delegation RRsets. 460 o Empty answer section (no records). 461 o Some other response. 462 o An error. 463 464 DNSSEC allocates two new bits in the DNS message header: the CD 465 (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit 466 is controlled by resolvers; a security-aware name server MUST copy 467 the CD bit from a query into the corresponding response. The AD bit 468 is controlled by name servers; a security-aware name server MUST 469 ignore the setting of the AD bit in queries. See Sections 3.1.6, 470 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. 471 472 A security aware name server that synthesizes CNAME RRs from DNAME 473 RRs as described in [RFC2672] SHOULD NOT generate signatures for the 474 synthesized CNAME RRs. 475 476 3.1. Authoritative Name Servers 477 478 Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT 479 pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name 480 server for a signed zone MUST include additional RRSIG, NSEC, and DS 481 RRs, according to the following rules: 482 483 o RRSIG RRs that can be used to authenticate a response MUST be 484 included in the response according to the rules in Section 3.1.1. 485 486 487 488 489 490 491 492 Arends, et al. Standards Track [Page 9] 493 RFC 4035 DNSSEC Protocol Modifications March 2005 494 495 496 o NSEC RRs that can be used to provide authenticated denial of 497 existence MUST be included in the response automatically according 498 to the rules in Section 3.1.3. 499 500 o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST 501 be included in referrals automatically according to the rules in 502 Section 3.1.4. 503 504 These rules only apply to responses where the semantics convey 505 information about the presence or absence of resource records. That 506 is, these rules are not intended to rule out responses such as RCODE 507 4 ("Not Implemented") or RCODE 5 ("Refused"). 508 509 DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 510 discusses zone transfer requirements. 511 512 3.1.1. Including RRSIG RRs in a Response 513 514 When responding to a query that has the DO bit set, a security-aware 515 authoritative name server SHOULD attempt to send RRSIG RRs that a 516 security-aware resolver can use to authenticate the RRsets in the 517 response. A name server SHOULD make every attempt to keep the RRset 518 and its associated RRSIG(s) together in a response. Inclusion of 519 RRSIG RRs in a response is subject to the following rules: 520 521 o When placing a signed RRset in the Answer section, the name server 522 MUST also place its RRSIG RRs in the Answer section. The RRSIG 523 RRs have a higher priority for inclusion than any other RRsets 524 that may have to be included. If space does not permit inclusion 525 of these RRSIG RRs, the name server MUST set the TC bit. 526 527 o When placing a signed RRset in the Authority section, the name 528 server MUST also place its RRSIG RRs in the Authority section. 529 The RRSIG RRs have a higher priority for inclusion than any other 530 RRsets that may have to be included. If space does not permit 531 inclusion of these RRSIG RRs, the name server MUST set the TC bit. 532 533 o When placing a signed RRset in the Additional section, the name 534 server MUST also place its RRSIG RRs in the Additional section. 535 If space does not permit inclusion of both the RRset and its 536 associated RRSIG RRs, the name server MAY retain the RRset while 537 dropping the RRSIG RRs. If this happens, the name server MUST NOT 538 set the TC bit solely because these RRSIG RRs didn't fit. 539 540 541 542 543 544 545 546 547 Arends, et al. Standards Track [Page 10] 548 RFC 4035 DNSSEC Protocol Modifications March 2005 549 550 551 3.1.2. Including DNSKEY RRs in a Response 552 553 When responding to a query that has the DO bit set and that requests 554 the SOA or NS RRs at the apex of a signed zone, a security-aware 555 authoritative name server for that zone MAY return the zone apex 556 DNSKEY RRset in the Additional section. In this situation, the 557 DNSKEY RRset and associated RRSIG RRs have lower priority than does 558 any other information that would be placed in the additional section. 559 The name server SHOULD NOT include the DNSKEY RRset unless there is 560 enough space in the response message for both the DNSKEY RRset and 561 its associated RRSIG RR(s). If there is not enough space to include 562 these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST 563 NOT set the TC bit solely because these RRs didn't fit (see Section 564 3.1.1). 565 566 3.1.3. Including NSEC RRs in a Response 567 568 When responding to a query that has the DO bit set, a security-aware 569 authoritative name server for a signed zone MUST include NSEC RRs in 570 each of the following cases: 571 572 No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> 573 but does not contain any RRsets that exactly match <SNAME, SCLASS, 574 STYPE>. 575 576 Name Error: The zone does not contain any RRsets that match <SNAME, 577 SCLASS> either exactly or via wildcard name expansion. 578 579 Wildcard Answer: The zone does not contain any RRsets that exactly 580 match <SNAME, SCLASS> but does contain an RRset that matches 581 <SNAME, SCLASS, STYPE> via wildcard name expansion. 582 583 Wildcard No Data: The zone does not contain any RRsets that exactly 584 match <SNAME, SCLASS> and does contain one or more RRsets that 585 match <SNAME, SCLASS> via wildcard name expansion, but does not 586 contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard 587 name expansion. 588 589 In each of these cases, the name server includes NSEC RRs in the 590 response to prove that an exact match for <SNAME, SCLASS, STYPE> was 591 not present in the zone and that the response that the name server is 592 returning is correct given the data in the zone. 593 594 595 596 597 598 599 600 601 602 Arends, et al. Standards Track [Page 11] 603 RFC 4035 DNSSEC Protocol Modifications March 2005 604 605 606 188.8.131.52. Including NSEC RRs: No Data Response 607 608 If the zone contains RRsets matching <SNAME, SCLASS> but contains no 609 RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST 610 include the NSEC RR for <SNAME, SCLASS> along with its associated 611 RRSIG RR(s) in the Authority section of the response (see Section 612 3.1.1). If space does not permit inclusion of the NSEC RR or its 613 associated RRSIG RR(s), the name server MUST set the TC bit (see 614 Section 3.1.1). 615 616 Since the search name exists, wildcard name expansion does not apply 617 to this query, and a single signed NSEC RR suffices to prove that the 618 requested RR type does not exist. 619 620 184.108.40.206. Including NSEC RRs: Name Error Response 621 622 If the zone does not contain any RRsets matching <SNAME, SCLASS> 623 either exactly or via wildcard name expansion, then the name server 624 MUST include the following NSEC RRs in the Authority section, along 625 with their associated RRSIG RRs: 626 627 o An NSEC RR proving that there is no exact match for <SNAME, 628 SCLASS>. 629 630 o An NSEC RR proving that the zone contains no RRsets that would 631 match <SNAME, SCLASS> via wildcard name expansion. 632 633 In some cases, a single NSEC RR may prove both of these points. If 634 it does, the name server SHOULD only include the NSEC RR and its 635 RRSIG RR(s) once in the Authority section. 636 637 If space does not permit inclusion of these NSEC and RRSIG RRs, the 638 name server MUST set the TC bit (see Section 3.1.1). 639 640 The owner names of these NSEC and RRSIG RRs are not subject to 641 wildcard name expansion when these RRs are included in the Authority 642 section of the response. 643 644 Note that this form of response includes cases in which SNAME 645 corresponds to an empty non-terminal name within the zone (a name 646 that is not the owner name for any RRset but that is the parent name 647 of one or more RRsets). 648 649 220.127.116.11. Including NSEC RRs: Wildcard Answer Response 650 651 If the zone does not contain any RRsets that exactly match <SNAME, 652 SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> 653 via wildcard name expansion, the name server MUST include the 654 655 656 657 Arends, et al. Standards Track [Page 12] 658 RFC 4035 DNSSEC Protocol Modifications March 2005 659 660 661 wildcard-expanded answer and the corresponding wildcard-expanded 662 RRSIG RRs in the Answer section and MUST include in the Authority 663 section an NSEC RR and associated RRSIG RR(s) proving that the zone 664 does not contain a closer match for <SNAME, SCLASS>. If space does 665 not permit inclusion of the answer, NSEC and RRSIG RRs, the name 666 server MUST set the TC bit (see Section 3.1.1). 667 668 18.104.22.168. Including NSEC RRs: Wildcard No Data Response 669 670 This case is a combination of the previous cases. The zone does not 671 contain an exact match for <SNAME, SCLASS>, and although the zone 672 does contain RRsets that match <SNAME, SCLASS> via wildcard 673 expansion, none of those RRsets matches STYPE. The name server MUST 674 include the following NSEC RRs in the Authority section, along with 675 their associated RRSIG RRs: 676 677 o An NSEC RR proving that there are no RRsets matching STYPE at the 678 wildcard owner name that matched <SNAME, SCLASS> via wildcard 679 expansion. 680 681 o An NSEC RR proving that there are no RRsets in the zone that would 682 have been a closer match for <SNAME, SCLASS>. 683 684 In some cases, a single NSEC RR may prove both of these points. If 685 it does, the name server SHOULD only include the NSEC RR and its 686 RRSIG RR(s) once in the Authority section. 687 688 The owner names of these NSEC and RRSIG RRs are not subject to 689 wildcard name expansion when these RRs are included in the Authority 690 section of the response. 691 692 If space does not permit inclusion of these NSEC and RRSIG RRs, the 693 name server MUST set the TC bit (see Section 3.1.1). 694 695 22.214.171.124. Finding the Right NSEC RRs 696 697 As explained above, there are several situations in which a 698 security-aware authoritative name server has to locate an NSEC RR 699 that proves that no RRsets matching a particular SNAME exist. 700 Locating such an NSEC RR within an authoritative zone is relatively 701 simple, at least in concept. The following discussion assumes that 702 the name server is authoritative for the zone that would have held 703 the non-existent RRsets matching SNAME. The algorithm below is 704 written for clarity, not for efficiency. 705 706 To find the NSEC that proves that no RRsets matching name N exist in 707 the zone Z that would have held them, construct a sequence, S, 708 consisting of the owner names of every RRset in Z, sorted into 709 710 711 712 Arends, et al. Standards Track [Page 13] 713 RFC 4035 DNSSEC Protocol Modifications March 2005 714 715 716 canonical order ([RFC4034]), with no duplicate names. Find the name 717 M that would have immediately preceded N in S if any RRsets with 718 owner name N had existed. M is the owner name of the NSEC RR that 719 proves that no RRsets exist with owner name N. 720 721 The algorithm for finding the NSEC RR that proves that a given name 722 is not covered by any applicable wildcard is similar but requires an 723 extra step. More precisely, the algorithm for finding the NSEC 724 proving that no RRsets exist with the applicable wildcard name is 725 precisely the same as the algorithm for finding the NSEC RR that 726 proves that RRsets with any other owner name do not exist. The part 727 that's missing is a method of determining the name of the non- 728 existent applicable wildcard. In practice, this is easy, because the 729 authoritative name server has already checked for the presence of 730 precisely this wildcard name as part of step (1)(c) of the normal 731 lookup algorithm described in Section 4.3.2 of [RFC1034]. 732 733 3.1.4. Including DS RRs in a Response 734 735 When responding to a query that has the DO bit set, a security-aware 736 authoritative name server returning a referral includes DNSSEC data 737 along with the NS RRset. 738 739 If a DS RRset is present at the delegation point, the name server 740 MUST return both the DS RRset and its associated RRSIG RR(s) in the 741 Authority section along with the NS RRset. 742 743 If no DS RRset is present at the delegation point, the name server 744 MUST return both the NSEC RR that proves that the DS RRset is not 745 present and the NSEC RR's associated RRSIG RR(s) along with the NS 746 RRset. The name server MUST place the NS RRset before the NSEC RRset 747 and its associated RRSIG RR(s). 748 749 Including these DS, NSEC, and RRSIG RRs increases the size of 750 referral messages and may cause some or all glue RRs to be omitted. 751 If space does not permit inclusion of the DS or NSEC RRset and 752 associated RRSIG RRs, the name server MUST set the TC bit (see 753 Section 3.1.1). 754 755 126.96.36.199. Responding to Queries for DS RRs 756 757 The DS resource record type is unusual in that it appears only on the 758 parent zone's side of a zone cut. For example, the DS RRset for the 759 delegation of "foo.example" is stored in the "example" zone rather 760 than in the "foo.example" zone. This requires special processing 761 rules for both name servers and resolvers, as the name server for the 762 child zone is authoritative for the name at the zone cut by the 763 normal DNS rules but the child zone does not contain the DS RRset. 764 765 766 767 Arends, et al. Standards Track [Page 14] 768 RFC 4035 DNSSEC Protocol Modifications March 2005 769 770 771 A security-aware resolver sends queries to the parent zone when 772 looking for a needed DS RR at a delegation point (see Section 4.2). 773 However, special rules are necessary to avoid confusing 774 security-oblivious resolvers which might become involved in 775 processing such a query (for example, in a network configuration that 776 forces a security-aware resolver to channel its queries through a 777 security-oblivious recursive name server). The rest of this section 778 describes how a security-aware name server processes DS queries in 779 order to avoid this problem. 780
RFC9077 updates many RFCs to clarify how TTLs are calculated
when using DNSSEC. For RFC 4035, it replaces:
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.
The TTL of the NSEC RR that is returned MUST be the lesser of the MINIMUM field of the SOA record and the TTL of the SOA itself. This matches the definition of the TTL for negative responses in [RFC2308]. Because some signers incrementally update the NSEC chain, a transient inconsistency between the observed and expected TTL MAY exist.
781 The need for special processing by a security-aware name server only 782 arises when all the following conditions are met: 783 784 o The name server has received a query for the DS RRset at a zone 785 cut. 786 787 o The name server is authoritative for the child zone. 788 789 o The name server is not authoritative for the parent zone. 790 791 o The name server does not offer recursion. 792 793 In all other cases, the name server either has some way of obtaining 794 the DS RRset or could not have been expected to have the DS RRset 795 even by the pre-DNSSEC processing rules, so the name server can 796 return either the DS RRset or an error response according to the 797 normal processing rules. 798 799 If all the above conditions are met, however, the name server is 800 authoritative for SNAME but cannot supply the requested RRset. In 801 this case, the name server MUST return an authoritative "no data" 802 response showing that the DS RRset does not exist in the child zone's 803 apex. See Appendix B.8 for an example of such a response. 804 805 3.1.5. Responding to Queries for Type AXFR or IXFR 806 807 DNSSEC does not change the DNS zone transfer process. A signed zone 808 will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these 809 records have no special meaning with respect to a zone transfer 810 operation. 811 812 An authoritative name server is not required to verify that a zone is 813 properly signed before sending or accepting a zone transfer. 814 However, an authoritative name server MAY choose to reject the entire 815 zone transfer if the zone fails to meet any of the signing 816 requirements described in Section 2. The primary objective of a zone 817 transfer is to ensure that all authoritative name servers have 818 identical copies of the zone. An authoritative name server that 819 820 821 822 Arends, et al. Standards Track [Page 15] 823 RFC 4035 DNSSEC Protocol Modifications March 2005 824 825 826 chooses to perform its own zone validation MUST NOT selectively 827 reject some RRs and accept others. 828 829 DS RRsets appear only on the parental side of a zone cut and are 830 authoritative data in the parent zone. As with any other 831 authoritative RRset, the DS RRset MUST be included in zone transfers 832 of the zone in which the RRset is authoritative data. In the case of 833 the DS RRset, this is the parent zone. 834 835 NSEC RRs appear in both the parent and child zones at a zone cut and 836 are authoritative data in both the parent and child zones. The 837 parental and child NSEC RRs at a zone cut are never identical to each 838 other, as the NSEC RR in the child zone's apex will always indicate 839 the presence of the child zone's SOA RR whereas the parental NSEC RR 840 at the zone cut will never indicate the presence of an SOA RR. As 841 with any other authoritative RRs, NSEC RRs MUST be included in zone 842 transfers of the zone in which they are authoritative data. The 843 parental NSEC RR at a zone cut MUST be included in zone transfers of 844 the parent zone, and the NSEC at the zone apex of the child zone MUST 845 be included in zone transfers of the child zone. 846 847 RRSIG RRs appear in both the parent and child zones at a zone cut and 848 are authoritative in whichever zone contains the authoritative RRset 849 for which the RRSIG RR provides the signature. That is, the RRSIG RR 850 for a DS RRset or a parental NSEC RR at a zone cut will be 851 authoritative in the parent zone, and the RRSIG for any RRset in the 852 child zone's apex will be authoritative in the child zone. Parental 853 and child RRSIG RRs at a zone cut will never be identical to each 854 other, as the Signer's Name field of an RRSIG RR in the child zone's 855 apex will indicate a DNSKEY RR in the child zone's apex whereas the 856 same field of a parental RRSIG RR at the zone cut will indicate a 857 DNSKEY RR in the parent zone's apex. As with any other authoritative 858 RRs, RRSIG RRs MUST be included in zone transfers of the zone in 859 which they are authoritative data. 860 861 3.1.6. The AD and CD Bits in an Authoritative Response 862 863 The CD and AD bits are designed for use in communication between 864 security-aware resolvers and security-aware recursive name servers. 865 These bits are for the most part not relevant to query processing by 866 security-aware authoritative name servers. 867 868 A security-aware name server does not perform signature validation 869 for authoritative data during query processing, even when the CD bit 870 is clear. A security-aware name server SHOULD clear the CD bit when 871 composing an authoritative response. 872 873 874 875 876 877 Arends, et al. Standards Track [Page 16] 878 RFC 4035 DNSSEC Protocol Modifications March 2005 879 880 881 A security-aware name server MUST NOT set the AD bit in a response 882 unless the name server considers all RRsets in the Answer and 883 Authority sections of the response to be authentic. A security-aware 884 name server's local policy MAY consider data from an authoritative 885 zone to be authentic without further validation. However, the name 886 server MUST NOT do so unless the name server obtained the 887 authoritative zone via secure means (such as a secure zone transfer 888 mechanism) and MUST NOT do so unless this behavior has been 889 configured explicitly. 890 891 A security-aware name server that supports recursion MUST follow the 892 rules for the CD and AD bits given in Section 3.2 when generating a 893 response that involves data obtained via recursion. 894 895 3.2. Recursive Name Servers 896 897 As explained in [RFC4033], a security-aware recursive name server is 898 an entity that acts in both the security-aware name server and 899 security-aware resolver roles. This section uses the terms "name 900 server side" and "resolver side" to refer to the code within a 901 security-aware recursive name server that implements the 902 security-aware name server role and the code that implements the 903 security-aware resolver role, respectively. 904 905 The resolver side follows the usual rules for caching and negative 906 caching that would apply to any security-aware resolver. 907 908 3.2.1. The DO Bit 909 910 The resolver side of a security-aware recursive name server MUST set 911 the DO bit when sending requests, regardless of the state of the DO 912 bit in the initiating request received by the name server side. If 913 the DO bit in an initiating query is not set, the name server side 914 MUST strip any authenticating DNSSEC RRs from the response but MUST 915 NOT strip any DNSSEC RR types that the initiating query explicitly 916 requested. 917
The need for special processing by a security-aware name server only arises when all the following conditions are met: o The name server has received a query for the DS RRset at a zone cut. o The name server is authoritative for the child zone. o The name server is not authoritative for the parent zone. o The name server does not offer recursion.
The need for special processing by a security-aware name server only arises when all the following conditions are met: o The name server has received a query for the DS RRset at a zone cut. o The name server is authoritative for the child zone. o The name server is not authoritative for
the parent zone. o The name server does not offer recursion.
918 3.2.2. The CD Bit 919 920 The CD bit exists in order to allow a security-aware resolver to 921 disable signature validation in a security-aware name server's 922 processing of a particular query. 923 924 The name server side MUST copy the setting of the CD bit from a query 925 to the corresponding response. 926 927 The name server side of a security-aware recursive name server MUST 928 pass the state of the CD bit to the resolver side along with the rest 929 930 931 932 Arends, et al. Standards Track [Page 17] 933 RFC 4035 DNSSEC Protocol Modifications March 2005 934 935 936 of an initiating query, so that the resolver side will know whether 937 it is required to verify the response data it returns to the name 938 server side. If the CD bit is set, it indicates that the originating 939 resolver is willing to perform whatever authentication its local 940 policy requires. Thus, the resolver side of the recursive name 941 server need not perform authentication on the RRsets in the response. 942 When the CD bit is set, the recursive name server SHOULD, if 943 possible, return the requested data to the originating resolver, even 944 if the recursive name server's local authentication policy would 945 reject the records in question. That is, by setting the CD bit, the 946 originating resolver has indicated that it takes responsibility for 947 performing its own authentication, and the recursive name server 948 should not interfere. 949 950 If the resolver side implements a BAD cache (see Section 4.7) and the 951 name server side receives a query that matches an entry in the 952 resolver side's BAD cache, the name server side's response depends on 953 the state of the CD bit in the original query. If the CD bit is set, 954 the name server side SHOULD return the data from the BAD cache; if 955 the CD bit is not set, the name server side MUST return RCODE 2 956 (server failure). 957 958 The intent of the above rule is to provide the raw data to clients 959 that are capable of performing their own signature verification 960 checks while protecting clients that depend on the resolver side of a 961 security-aware recursive name server to perform such checks. Several 962 of the possible reasons why signature validation might fail involve 963 conditions that may not apply equally to the recursive name server 964 and the client that invoked it. For example, the recursive name 965 server's clock may be set incorrectly, or the client may have 966 knowledge of a relevant island of security that the recursive name 967 server does not share. In such cases, "protecting" a client that is 968 capable of performing its own signature validation from ever seeing 969 the "bad" data does not help the client. 970
Section 5.9 of RFC6840 says:
When processing a request with the Checking Disabled (CD) bit set, a resolver SHOULD attempt to return all response data, even data that has failed DNSSEC validation. Section 3.2.2 of [RFC4035] requires a resolver processing a request with the CD bit set to set the CD bit on its upstream queries. This document further specifies that validating resolvers SHOULD set the CD bit on every upstream query. This is regardless of whether the CD bit was set on the incoming query or whether it has a trust anchor at or above the QNAME. [RFC4035] is ambiguous about what to do when a cached response was obtained with the CD bit unset, a case that only arises when the resolver chooses not to set the CD bit on all upstream queries, as specified above. In the typical case, no new query is required, nor does the cache need to track the state of the CD bit used to make a given query. The problem arises when the cached response is a server failure (RCODE 2), which may indicate that the requested data failed DNSSEC validation at an upstream validating resolver. ([RFC2308] permits caching of server failures for up to five minutes.) In these cases, a new query with the CD bit set is required.
Be sure to read Appendix B of RFC6840, which details the logic behind the recommendation to alwas set the CD bit on queries.
971 3.2.3. The AD Bit 972 973 The name server side of a security-aware recursive name server MUST 974 NOT set the AD bit in a response unless the name server considers all 975 RRsets in the Answer and Authority sections of the response to be 976 authentic. The name server side SHOULD set the AD bit if and only if 977 the resolver side considers all RRsets in the Answer section and any 978 relevant negative response RRs in the Authority section to be 979 authentic. The resolver side MUST follow the procedure described in 980 Section 5 to determine whether the RRs in question are authentic. 981 However, for backward compatibility, a recursive name server MAY set 982 the AD bit when a response includes unsigned CNAME RRs if those CNAME 983 984 985 986 987 Arends, et al. Standards Track [Page 18] 988 RFC 4035 DNSSEC Protocol Modifications March 2005 989 990 991 RRs demonstrably could have been synthesized from an authentic DNAME 992 RR that is also included in the response according to the synthesis 993 rules described in [RFC2672]. 994 995 3.3. Example DNSSEC Responses 996 997 See Appendix B for example response packets. 998 999 4. Resolving 1000 1001 This section describes the behavior of entities that include 1002 security-aware resolver functions. In many cases such functions will 1003 be part of a security-aware recursive name server, but a stand-alone 1004 security-aware resolver has many of the same requirements. Functions 1005 specific to security-aware recursive name servers are described in 1006 Section 3.2. 1007 1008 4.1. EDNS Support 1009 1010 A security-aware resolver MUST include an EDNS ([RFC2671]) OPT 1011 pseudo-RR with the DO ([RFC3225]) bit set when sending queries. 1012 1013 A security-aware resolver MUST support a message size of at least 1014 1220 octets, SHOULD support a message size of 4000 octets, and MUST 1015 use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR 1016 to advertise the message size that it is willing to accept. A 1017 security-aware resolver's IP layer MUST handle fragmented UDP packets 1018 correctly regardless of whether any such fragmented packets were 1019 received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and 1020 [RFC3226] for discussion of these requirements. 1021 1022 4.2. Signature Verification Support 1023 1024 A security-aware resolver MUST support the signature verification 1025 mechanisms described in Section 5 and SHOULD apply them to every 1026 received response, except when: 1027 1028 o the security-aware resolver is part of a security-aware recursive 1029 name server, and the response is the result of recursion on behalf 1030 of a query received with the CD bit set; 1031 1032 o the response is the result of a query generated directly via some 1033 form of application interface that instructed the security-aware 1034 resolver not to perform validation for this query; or 1035 1036 o validation for this query has been disabled by local policy. 1037 1038 1039 1040 1041 1042 Arends, et al. Standards Track [Page 19] 1043 RFC 4035 DNSSEC Protocol Modifications March 2005 1044 1045 1046 A security-aware resolver's support for signature verification MUST 1047 include support for verification of wildcard owner names. 1048 1049 Security-aware resolvers MAY query for missing security RRs in an 1050 attempt to perform validation; implementations that choose to do so 1051 must be aware that the answers received may not be sufficient to 1052 validate the original response. For example, a zone update may have 1053 changed (or deleted) the desired information between the original and 1054 follow-up queries. 1055 1056 When attempting to retrieve missing NSEC RRs that reside on the 1057 parental side at a zone cut, a security-aware iterative-mode resolver 1058 MUST query the name servers for the parent zone, not the child zone. 1059 1060 When attempting to retrieve a missing DS, a security-aware 1061 iterative-mode resolver MUST query the name servers for the parent 1062 zone, not the child zone. As explained in Section 188.8.131.52, 1063 security-aware name servers need to apply special processing rules to 1064 handle the DS RR, and in some situations the resolver may also need 1065 to apply special rules to locate the name servers for the parent zone 1066 if the resolver does not already have the parent's NS RRset. To 1067 locate the parent NS RRset, the resolver can start with the 1068 delegation name, strip off the leftmost label, and query for an NS 1069 RRset by that name. If no NS RRset is present at that name, the 1070 resolver then strips off the leftmost remaining label and retries the 1071 query for that name, repeating this process of walking up the tree 1072 until it either finds the NS RRset or runs out of labels. 1073 1074 4.3. Determining Security Status of Data 1075 1076 A security-aware resolver MUST be able to determine whether it should 1077 expect a particular RRset to be signed. More precisely, a 1078 security-aware resolver must be able to distinguish between four 1079 cases: 1080 1081 Secure: An RRset for which the resolver is able to build a chain of 1082 signed DNSKEY and DS RRs from a trusted security anchor to the 1083 RRset. In this case, the RRset should be signed and is subject to 1084 signature validation, as described above. 1085 1086 Insecure: An RRset for which the resolver knows that it has no chain 1087 of signed DNSKEY and DS RRs from any trusted starting point to the 1088 RRset. This can occur when the target RRset lies in an unsigned 1089 zone or in a descendent of an unsigned zone. In this case, the 1090 RRset may or may not be signed, but the resolver will not be able 1091 to verify the signature. 1092 1093 1094 1095 1096 1097 Arends, et al. Standards Track [Page 20] 1098 RFC 4035 DNSSEC Protocol Modifications March 2005 1099 1100 1101 Bogus: An RRset for which the resolver believes that it ought to be 1102 able to establish a chain of trust but for which it is unable to 1103 do so, either due to signatures that for some reason fail to 1104 validate or due to missing data that the relevant DNSSEC RRs 1105 indicate should be present. This case may indicate an attack but 1106 may also indicate a configuration error or some form of data 1107 corruption. 1108 1109 Indeterminate: An RRset for which the resolver is not able to 1110 determine whether the RRset should be signed, as the resolver is 1111 not able to obtain the necessary DNSSEC RRs. This can occur when 1112 the security-aware resolver is not able to contact security-aware 1113 name servers for the relevant zones. 1114 1115 4.4. Configured Trust Anchors 1116 1117 A security-aware resolver MUST be capable of being configured with at 1118 least one trusted public key or DS RR and SHOULD be capable of being 1119 configured with multiple trusted public keys or DS RRs. Since a 1120 security-aware resolver will not be able to validate signatures 1121 without such a configured trust anchor, the resolver SHOULD have some 1122 reasonably robust mechanism for obtaining such keys when it boots; 1123 examples of such a mechanism would be some form of non-volatile 1124 storage (such as a disk drive) or some form of trusted local network 1125 configuration mechanism. 1126 1127 Note that trust anchors also cover key material that is updated in a 1128 secure manner. This secure manner could be through physical media, a 1129 key exchange protocol, or some other out-of-band means. 1130 1131 4.5. Response Caching 1132 1133 A security-aware resolver SHOULD cache each response as a single 1134 atomic entry containing the entire answer, including the named RRset 1135 and any associated DNSSEC RRs. The resolver SHOULD discard the 1136 entire atomic entry when any of the RRs contained in it expire. In 1137 most cases the appropriate cache index for the atomic entry will be 1138 the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response 1139 form described in Section 184.108.40.206 the appropriate cache index will be 1140 the double <QNAME,QCLASS>. 1141 1142 The reason for these recommendations is that, between the initial 1143 query and the expiration of the data from the cache, the 1144 authoritative data might have been changed (for example, via dynamic 1145 update). 1146 1147 1148 1149 1150 1151 1152 Arends, et al. Standards Track [Page 21] 1153 RFC 4035 DNSSEC Protocol Modifications March 2005 1154 1155 1156 There are two situations for which this is relevant: 1157 1158 1. By using the RRSIG record, it is possible to deduce that an 1159 answer was synthesized from a wildcard. A security-aware 1160 recursive name server could store this wildcard data and use it 1161 to generate positive responses to queries other than the name for 1162 which the original answer was first received. 1163 1164 2. NSEC RRs received to prove the non-existence of a name could be 1165 reused by a security-aware resolver to prove the non-existence of 1166 any name in the name range it spans. 1167
Section 5.8 of RFC6840 says:
Section 3.2.3 of [RFC4035] describes under which conditions a validating resolver should set or clear the AD bit in a response. In order to interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit.
1168 In theory, a resolver could use wildcards or NSEC RRs to generate 1169 positive and negative responses (respectively) until the TTL or 1170 signatures on the records in question expire. However, it seems 1171 prudent for resolvers to avoid blocking new authoritative data or 1172 synthesizing new data on their own. Resolvers that follow this 1173 recommendation will have a more consistent view of the namespace. 1174
The abstract of RFC8198 says
"This document updates RFC 4035 by allowing validating resolvers to
generate negative answers based upon NSEC/NSEC3 records and positive
answers in the presence of wildcards."
In specific, it replaces this pargraph ("In theory, a resolver...") with:
Once the records are validated, DNSSEC-enabled validating resolvers SHOULD use wildcards and NSEC/NSEC3 resource records to generate positive and negative responses until the effective TTLs or signatures for those records expire.
1175 4.6. Handling of the CD and AD Bits 1176 1177 A security-aware resolver MAY set a query's CD bit in order to 1178 indicate that the resolver takes responsibility for performing 1179 whatever authentication its local policy requires on the RRsets in 1180 the response. See Section 3.2 for the effect this bit has on the 1181 behavior of security-aware recursive name servers. 1182 1183 A security-aware resolver MUST clear the AD bit when composing query 1184 messages to protect against buggy name servers that blindly copy 1185 header bits that they do not understand from the query message to the 1186 response message. 1187 1188 A resolver MUST disregard the meaning of the CD and AD bits in a 1189 response unless the response was obtained by using a secure channel 1190 or the resolver was specifically configured to regard the message 1191 header bits without using a secure channel. 1192
Section 5.7 of RFC6840 says:
The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit.
Further, Section 5.8 of RFC6840 says:
Section 3.2.3 of [RFC4035] describes under which conditions a validating resolver should set or clear the AD bit in a response. In order to interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit.
1193 4.7. Caching BAD Data 1194 1195 While many validation errors will be transient, some are likely to be 1196 more persistent, such as those caused by administrative error 1197 (failure to re-sign a zone, clock skew, and so forth). Since 1198 requerying will not help in these cases, validating resolvers might 1199 generate a significant amount of unnecessary DNS traffic as a result 1200 of repeated queries for RRsets with persistent validation failures. 1201 1202 To prevent such unnecessary DNS traffic, security-aware resolvers MAY 1203 cache data with invalid signatures, with some restrictions. 1204 1205 1206 1207 Arends, et al. Standards Track [Page 22] 1208 RFC 4035 DNSSEC Protocol Modifications March 2005 1209 1210 1211 Conceptually, caching such data is similar to negative caching 1212 ([RFC2308]), except that instead of caching a valid negative 1213 response, the resolver is caching the fact that a particular answer 1214 failed to validate. This document refers to a cache of data with 1215 invalid signatures as a "BAD cache". 1216 1217 Resolvers that implement a BAD cache MUST take steps to prevent the 1218 cache from being useful as a denial-of-service attack amplifier, 1219 particularly the following: 1220 1221 o Since RRsets that fail to validate do not have trustworthy TTLs, 1222 the implementation MUST assign a TTL. This TTL SHOULD be small, 1223 in order to mitigate the effect of caching the results of an 1224 attack. 1225 1226 o In order to prevent caching of a transient validation failure 1227 (which might be the result of an attack), resolvers SHOULD track 1228 queries that result in validation failures and SHOULD only answer 1229 from the BAD cache after the number of times that responses to 1230 queries for that particular <QNAME, QTYPE, QCLASS> have failed to 1231 validate exceeds a threshold value. 1232 1233 Resolvers MUST NOT return RRsets from the BAD cache unless the 1234 resolver is not required to validate the signatures of the RRsets in 1235 question under the rules given in Section 4.2 of this document. See 1236 Section 3.2.2 for discussion of how the responses returned by a 1237 security-aware recursive name server interact with a BAD cache. 1238 1239 4.8. Synthesized CNAMEs 1240 1241 A validating security-aware resolver MUST treat the signature of a 1242 valid signed DNAME RR as also covering unsigned CNAME RRs that could 1243 have been synthesized from the DNAME RR, as described in [RFC2672], 1244 at least to the extent of not rejecting a response message solely 1245 because it contains such CNAME RRs. The resolver MAY retain such 1246 CNAME RRs in its cache or in the answers it hands back, but is not 1247 required to do so. 1248 1249 4.9. Stub Resolvers 1250 1251 A security-aware stub resolver MUST support the DNSSEC RR types, at 1252 least to the extent of not mishandling responses just because they 1253 contain DNSSEC RRs. 1254 1255 1256 1257 1258 1259 1260 1261 1262 Arends, et al. Standards Track [Page 23] 1263 RFC 4035 DNSSEC Protocol Modifications March 2005 1264 1265 1266 4.9.1. Handling of the DO Bit 1267 1268 A non-validating security-aware stub resolver MAY include the DNSSEC 1269 RRs returned by a security-aware recursive name server as part of the 1270 data that the stub resolver hands back to the application that 1271 invoked it, but is not required to do so. A non-validating stub 1272 resolver that seeks to do this will need to set the DO bit in order 1273 to receive DNSSEC RRs from the recursive name server. 1274 1275 A validating security-aware stub resolver MUST set the DO bit, 1276 because otherwise it will not receive the DNSSEC RRs it needs to 1277 perform signature validation. 1278 1279 4.9.2. Handling of the CD Bit 1280 1281 A non-validating security-aware stub resolver SHOULD NOT set the CD 1282 bit when sending queries unless it is requested by the application 1283 layer, as by definition, a non-validating stub resolver depends on 1284 the security-aware recursive name server to perform validation on its 1285 behalf. 1286 1287 A validating security-aware stub resolver SHOULD set the CD bit, 1288 because otherwise the security-aware recursive name server will 1289 answer the query using the name server's local policy, which may 1290 prevent the stub resolver from receiving data that would be 1291 acceptable to the stub resolver's local policy. 1292 1293 4.9.3. Handling of the AD Bit 1294 1295 A non-validating security-aware stub resolver MAY chose to examine 1296 the setting of the AD bit in response messages that it receives in 1297 order to determine whether the security-aware recursive name server 1298 that sent the response claims to have cryptographically verified the 1299 data in the Answer and Authority sections of the response message. 1300 Note, however, that the responses received by a security-aware stub 1301 resolver are heavily dependent on the local policy of the 1302 security-aware recursive name server. Therefore, there may be little 1303 practical value in checking the status of the AD bit, except perhaps 1304 as a debugging aid. In any case, a security-aware stub resolver MUST 1305 NOT place any reliance on signature validation allegedly performed on 1306 its behalf, except when the security-aware stub resolver obtained the 1307 data in question from a trusted security-aware recursive name server 1308 via a secure channel. 1309 1310 A validating security-aware stub resolver SHOULD NOT examine the 1311 setting of the AD bit in response messages, as, by definition, the 1312 stub resolver performs its own signature validation regardless of the 1313 setting of the AD bit. 1314 1315 1316 1317 Arends, et al. Standards Track [Page 24] 1318 RFC 4035 DNSSEC Protocol Modifications March 2005 1319 1320
Section 3.1 of RFC6840 says:
Section 4.7 of [RFC4035] permits security-aware resolvers to implement a BAD cache. That guidance has changed: security-aware resolvers SHOULD implement a BAD cache as described in [RFC4035]. This change in guidance is based on operational experience with DNSSEC administrative errors leading to significant increases in DNS traffic, with an accompanying realization that such events are more likely and more damaging than originally supposed. An example of one such event is documented in "Rolling Over DNSSEC Keys" [Huston].
1321 5. Authenticating DNS Responses 1322 1323 To use DNSSEC RRs for authentication, a security-aware resolver 1324 requires configured knowledge of at least one authenticated DNSKEY or 1325 DS RR. The process for obtaining and authenticating this initial 1326 trust anchor is achieved via some external mechanism. For example, a 1327 resolver could use some off-line authenticated exchange to obtain a 1328 zone's DNSKEY RR or to obtain a DS RR that identifies and 1329 authenticates a zone's DNSKEY RR. The remainder of this section 1330 assumes that the resolver has somehow obtained an initial set of 1331 trust anchors. 1332 1333 An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY 1334 RRset. To authenticate an apex DNSKEY RRset by using an initial key, 1335 the resolver MUST: 1336 1337 1. verify that the initial DNSKEY RR appears in the apex DNSKEY 1338 RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA 1339 bit 7) set; and 1340 1341 2. verify that there is some RRSIG RR that covers the apex DNSKEY 1342 RRset, and that the combination of the RRSIG RR and the initial 1343 DNSKEY RR authenticates the DNSKEY RRset. The process for using 1344 an RRSIG RR to authenticate an RRset is described in Section 5.3. 1345 1346 Once the resolver has authenticated the apex DNSKEY RRset by using an 1347 initial DNSKEY RR, delegations from that zone can be authenticated by 1348 using DS RRs. This allows a resolver to start from an initial key 1349 and use DS RRsets to proceed recursively down the DNS tree, obtaining 1350 other apex DNSKEY RRsets. If the resolver were configured with a 1351 root DNSKEY RR, and if every delegation had a DS RR associated with 1352 it, then the resolver could obtain and validate any apex DNSKEY 1353 RRset. The process of using DS RRs to authenticate referrals is 1354 described in Section 5.2. 1355 1356 Section 5.3 shows how the resolver can use DNSKEY RRs in the apex 1357 DNSKEY RRset and RRSIG RRs from the zone to authenticate any other 1358 RRsets in the zone once the resolver has authenticated a zone's apex 1359 DNSKEY RRset. Section 5.4 shows how the resolver can use 1360 authenticated NSEC RRsets from the zone to prove that an RRset is not 1361 present in the zone. 1362 1363 When a resolver indicates support for DNSSEC (by setting the DO bit), 1364 a security-aware name server should attempt to provide the necessary 1365 DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). 1366 However, a security-aware resolver may still receive a response that 1367 lacks the appropriate DNSSEC RRs, whether due to configuration issues 1368 such as an upstream security-oblivious recursive name server that 1369 1370 1371 1372 Arends, et al. Standards Track [Page 25] 1373 RFC 4035 DNSSEC Protocol Modifications March 2005 1374 1375 1376 accidentally interferes with DNSSEC RRs or due to a deliberate attack 1377 in which an adversary forges a response, strips DNSSEC RRs from a 1378 response, or modifies a query so that DNSSEC RRs appear not to be 1379 requested. The absence of DNSSEC data in a response MUST NOT by 1380 itself be taken as an indication that no authentication information 1381 exists. 1382 1383 A resolver SHOULD expect authentication information from signed 1384 zones. A resolver SHOULD believe that a zone is signed if the 1385 resolver has been configured with public key information for the 1386 zone, or if the zone's parent is signed and the delegation from the 1387 parent contains a DS RRset. 1388 1389 5.1. Special Considerations for Islands of Security 1390 1391 Islands of security (see [RFC4033]) are signed zones for which it is 1392 not possible to construct an authentication chain to the zone from 1393 its parent. Validating signatures within an island of security 1394 requires that the validator have some other means of obtaining an 1395 initial authenticated zone key for the island. If a validator cannot 1396 obtain such a key, it SHOULD switch to operating as if the zones in 1397 the island of security are unsigned. 1398 1399 All the normal processes for validating responses apply to islands of 1400 security. The only difference between normal validation and 1401 validation within an island of security is in how the validator 1402 obtains a trust anchor for the authentication chain. 1403
Section 4.3 of RFC6840 says:
Section 5 of [RFC4035] says nothing explicit about validating responses based on (or that should be based on) CNAMEs. When validating a NOERROR/NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the bit for the query type. Without this check, an attacker could successfully transform a positive CNAME response into a NOERROR/NODATA response by (for example) simply stripping the CNAME RRset from the response. A naive validator would then note that the QTYPE was not present in the matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was set; thus, the response should have been a positive CNAME response.
1404 5.2. Authenticating Referrals 1405 1406 Once the apex DNSKEY RRset for a signed parent zone has been 1407 authenticated, DS RRsets can be used to authenticate the delegation 1408 to a signed child zone. A DS RR identifies a DNSKEY RR in the child 1409 zone's apex DNSKEY RRset and contains a cryptographic digest of the 1410 child zone's DNSKEY RR. Use of a strong cryptographic digest 1411 algorithm ensures that it is computationally infeasible for an 1412 adversary to generate a DNSKEY RR that matches the digest. Thus, 1413 authenticating the digest allows a resolver to authenticate the 1414 matching DNSKEY RR. The resolver can then use this child DNSKEY RR 1415 to authenticate the entire child apex DNSKEY RRset. 1416 1417 Given a DS RR for a delegation, the child zone's apex DNSKEY RRset 1418 can be authenticated if all of the following hold: 1419 1420 o The DS RR has been authenticated using some DNSKEY RR in the 1421 parent's apex DNSKEY RRset (see Section 5.3). 1422 1423 1424 1425 1426 1427 Arends, et al. Standards Track [Page 26] 1428 RFC 4035 DNSSEC Protocol Modifications March 2005 1429 1430 1431 o The Algorithm and Key Tag in the DS RR match the Algorithm field 1432 and the key tag of a DNSKEY RR in the child zone's apex DNSKEY 1433 RRset, and, when the DNSKEY RR's owner name and RDATA are hashed 1434 using the digest algorithm specified in the DS RR's Digest Type 1435 field, the resulting digest value matches the Digest field of the 1436 DS RR. 1437 1438 o The matching DNSKEY RR in the child zone has the Zone Flag bit 1439 set, the corresponding private key has signed the child zone's 1440 apex DNSKEY RRset, and the resulting RRSIG RR authenticates the 1441 child zone's apex DNSKEY RRset. 1442 1443 If the referral from the parent zone did not contain a DS RRset, the 1444 response should have included a signed NSEC RRset proving that no DS 1445 RRset exists for the delegated name (see Section 3.1.4). A 1446 security-aware resolver MUST query the name servers for the parent 1447 zone for the DS RRset if the referral includes neither a DS RRset nor 1448 a NSEC RRset proving that the DS RRset does not exist (see Section 1449 4). 1450 1451 If the validator authenticates an NSEC RRset that proves that no DS 1452 RRset is present for this zone, then there is no authentication path 1453 leading from the parent to the child. If the resolver has an initial 1454 DNSKEY or DS RR that belongs to the child zone or to any delegation 1455 below the child zone, this initial DNSKEY or DS RR MAY be used to 1456 re-establish an authentication path. If no such initial DNSKEY or DS 1457 RR exists, the validator cannot authenticate RRsets in or below the 1458 child zone. 1459
Section 4.4 of RFC6840 says:
Section 5.2 of [RFC4035] specifies that a validator, when proving a delegation is not secure, needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also MUST check for the presence of the NS bit in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation), or alternately make sure that the delegation is covered by an NSEC3 RR with the Opt-Out flag set. Without this check, an attacker could reuse an NSEC or NSEC3 RR matching a non-delegation name to spoof an unsigned delegation at that name. This would claim that an existing signed RRset (or set of signed RRsets) is below an unsigned delegation, thus not signed and vulnerable to further attack.
Section 5.3 of RFC6840 gives an extensive discussion of how to handle zones that are signed with private algorithms. It extends the processing given in Section 5.2 of RFC 4035.
1460 If the validator does not support any of the algorithms listed in an 1461 authenticated DS RRset, then the resolver has no supported 1462 authentication path leading from the parent to the child. The 1463 resolver should treat this case as it would the case of an 1464 authenticated NSEC RRset proving that no DS RRset exists, as 1465 described above. 1466 1467 Note that, for a signed delegation, there are two NSEC RRs associated 1468 with the delegated name. One NSEC RR resides in the parent zone and 1469 can be used to prove whether a DS RRset exists for the delegated 1470 name. The second NSEC RR resides in the child zone and identifies 1471 which RRsets are present at the apex of the child zone. The parent 1472 NSEC RR and child NSEC RR can always be distinguished because the SOA 1473 bit will be set in the child NSEC RR and clear in the parent NSEC RR. 1474 A security-aware resolver MUST use the parent NSEC RR when attempting 1475 to prove that a DS RRset does not exist. 1476 1477 1478 1479 1480 1481 1482 Arends, et al. Standards Track [Page 27] 1483 RFC 4035 DNSSEC Protocol Modifications March 2005 1484 1485 1486 If the resolver does not support any of the algorithms listed in an 1487 authenticated DS RRset, then the resolver will not be able to verify 1488 the authentication path to the child zone. In this case, the 1489 resolver SHOULD treat the child zone as if it were unsigned. 1490
Section 5.2 of RFC6840 says:
In other words, when determining the security status of a zone, a validator disregards any authenticated DS records that specify unknown or unsupported DNSKEY algorithms. If none are left, the zone is treated as if it were unsigned. This document modifies the above text to additionally disregard authenticated DS records using unknown or unsupported message digest algorithms.
1491 5.3. Authenticating an RRset with an RRSIG RR 1492 1493 A validator can use an RRSIG RR and its corresponding DNSKEY RR to 1494 attempt to authenticate RRsets. The validator first checks the RRSIG 1495 RR to verify that it covers the RRset, has a valid time interval, and 1496 identifies a valid DNSKEY RR. The validator then constructs the 1497 canonical form of the signed data by appending the RRSIG RDATA 1498 (excluding the Signature Field) with the canonical form of the 1499 covered RRset. Finally, the validator uses the public key and 1500 signature to authenticate the signed data. Sections 5.3.1, 5.3.2, 1501 and 5.3.3 describe each step in detail. 1502 1503 5.3.1. Checking the RRSIG RR Validity 1504 1505 A security-aware resolver can use an RRSIG RR to authenticate an 1506 RRset if all of the following conditions hold: 1507 1508 o The RRSIG RR and the RRset MUST have the same owner name and the 1509 same class. 1510 1511 o The RRSIG RR's Signer's Name field MUST be the name of the zone 1512 that contains the RRset. 1513 1514 o The RRSIG RR's Type Covered field MUST equal the RRset's type. 1515 1516 o The number of labels in the RRset owner name MUST be greater than 1517 or equal to the value in the RRSIG RR's Labels field. 1518 1519 o The validator's notion of the current time MUST be less than or 1520 equal to the time listed in the RRSIG RR's Expiration field. 1521 1522 o The validator's notion of the current time MUST be greater than or 1523 equal to the time listed in the RRSIG RR's Inception field. 1524 1525 o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST 1526 match the owner name, algorithm, and key tag for some DNSKEY RR in 1527 the zone's apex DNSKEY RRset. 1528 1529 o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY 1530 RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) 1531 set. 1532 1533 1534 1535 1536 1537 Arends, et al. Standards Track [Page 28] 1538 RFC 4035 DNSSEC Protocol Modifications March 2005 1539 1540 1541 It is possible for more than one DNSKEY RR to match the conditions 1542 above. In this case, the validator cannot predetermine which DNSKEY 1543 RR to use to authenticate the signature, and it MUST try each 1544 matching DNSKEY RR until either the signature is validated or the 1545 validator has run out of matching public keys to try. 1546 1547 Note that this authentication process is only meaningful if the 1548 validator authenticates the DNSKEY RR before using it to validate 1549 signatures. The matching DNSKEY RR is considered to be authentic if: 1550 1551 o the apex DNSKEY RRset containing the DNSKEY RR is considered 1552 authentic; or 1553 1554 o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, 1555 and the DNSKEY RR either matches an authenticated DS RR from the 1556 parent zone or matches a trust anchor. 1557 1558 5.3.2. Reconstructing the Signed Data 1559 1560 Once the RRSIG RR has met the validity requirements described in 1561 Section 5.3.1, the validator has to reconstruct the original signed 1562 data. The original signed data includes RRSIG RDATA (excluding the 1563 Signature field) and the canonical form of the RRset. Aside from 1564 being ordered, the canonical form of the RRset might also differ from 1565 the received RRset due to DNS name compression, decremented TTLs, or 1566 wildcard expansion. The validator should use the following to 1567 reconstruct the original signed data: 1568 1569 signed_data = RRSIG_RDATA | RR(1) | RR(2)... where 1570 1571 "|" denotes concatenation 1572 1573 RRSIG_RDATA is the wire format of the RRSIG RDATA fields 1574 with the Signature field excluded and the Signer's Name 1575 in canonical form. 1576 1577 RR(i) = name | type | class | OrigTTL | RDATA length | RDATA 1578 1579 name is calculated according to the function below 1580 1581 class is the RRset's class 1582 1583 type is the RRset type and all RRs in the class 1584 1585 OrigTTL is the value from the RRSIG Original TTL field 1586 1587 All names in the RDATA field are in canonical form 1588 1589 1590 1591 1592 Arends, et al. Standards Track [Page 29] 1593 RFC 4035 DNSSEC Protocol Modifications March 2005 1594 1595 1596 The set of all RR(i) is sorted into canonical order. 1597 1598 To calculate the name: 1599 let rrsig_labels = the value of the RRSIG Labels field 1600 1601 let fqdn = RRset's fully qualified domain name in 1602 canonical form 1603 1604 let fqdn_labels = Label count of the fqdn above. 1605 1606 if rrsig_labels = fqdn_labels, 1607 name = fqdn 1608 1609 if rrsig_labels < fqdn_labels, 1610 name = "*." | the rightmost rrsig_label labels of the 1611 fqdn 1612 1613 if rrsig_labels > fqdn_labels 1614 the RRSIG RR did not pass the necessary validation 1615 checks and MUST NOT be used to authenticate this 1616 RRset. 1617 1618 The canonical forms for names and RRsets are defined in [RFC4034]. 1619 1620 NSEC RRsets at a delegation boundary require special processing. 1621 There are two distinct NSEC RRsets associated with a signed delegated 1622 name. One NSEC RRset resides in the parent zone, and specifies which 1623 RRsets are present at the parent zone. The second NSEC RRset resides 1624 at the child zone and identifies which RRsets are present at the apex 1625 in the child zone. The parent NSEC RRset and child NSEC RRset can 1626 always be distinguished as only a child NSEC RR will indicate that an 1627 SOA RRset exists at the name. When reconstructing the original NSEC 1628 RRset for the delegation from the parent zone, the NSEC RRs MUST NOT 1629 be combined with NSEC RRs from the child zone. When reconstructing 1630 the original NSEC RRset for the apex of the child zone, the NSEC RRs 1631 MUST NOT be combined with NSEC RRs from the parent zone. 1632 1633 Note that each of the two NSEC RRsets at a delegation point has a 1634 corresponding RRSIG RR with an owner name matching the delegated 1635 name, and each of these RRSIG RRs is authoritative data associated 1636 with the same zone that contains the corresponding NSEC RRset. If 1637 necessary, a resolver can tell these RRSIG RRs apart by checking the 1638 Signer's Name field. 1639 1640 1641 1642 1643 1644 1645 1646 1647 Arends, et al. Standards Track [Page 30] 1648 RFC 4035 DNSSEC Protocol Modifications March 2005 1649 1650
Section 4.2 of RFC6840 says:
[RFC4035] does not address how to validate responses when QTYPE=*. As described in Section 6.2.2 of [RFC1034], a proper response to QTYPE=* may include a subset of the RRsets at a given name. That is, it is not necessary to include all RRsets at the QNAME in the response. When validating a response to QTYPE=*, all received RRsets that match QNAME and QCLASS MUST be validated. If any of those RRsets fail validation, the answer is considered Bogus. If there are no RRsets matching QNAME and QCLASS, that fact MUST be validated according to the rules in Section 5.4 of [RFC4035] (as clarified in this document). To be clear, a validator must not expect to receive all records at the QNAME in response to QTYPE=*.
1651 5.3.3. Checking the Signature 1652 1653 Once the resolver has validated the RRSIG RR as described in Section 1654 5.3.1 and reconstructed the original signed data as described in 1655 Section 5.3.2, the validator can attempt to use the cryptographic 1656 signature to authenticate the signed data, and thus (finally!) 1657 authenticate the RRset. 1658 1659 The Algorithm field in the RRSIG RR identifies the cryptographic 1660 algorithm used to generate the signature. The signature itself is 1661 contained in the Signature field of the RRSIG RDATA, and the public 1662 key used to verify the signature is contained in the Public Key field 1663 of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] 1664 provides a list of algorithm types and provides pointers to the 1665 documents that define each algorithm's use. 1666 1667 Note that it is possible for more than one DNSKEY RR to match the 1668 conditions in Section 5.3.1. In this case, the validator can only 1669 determine which DNSKEY RR is correct by trying each matching public 1670 key until the validator either succeeds in validating the signature 1671 or runs out of keys to try. 1672 1673 If the Labels field of the RRSIG RR is not equal to the number of 1674 labels in the RRset's fully qualified owner name, then the RRset is 1675 either invalid or the result of wildcard expansion. The resolver 1676 MUST verify that wildcard expansion was applied properly before 1677 considering the RRset to be authentic. Section 5.3.4 describes how 1678 to determine whether a wildcard was applied properly. 1679 1680 If other RRSIG RRs also cover this RRset, the local resolver security 1681 policy determines whether the resolver also has to test these RRSIG 1682 RRs and how to resolve conflicts if these RRSIG RRs lead to differing 1683 results. 1684 1685 If the resolver accepts the RRset as authentic, the validator MUST 1686 set the TTL of the RRSIG RR and each RR in the authenticated RRset to 1687 a value no greater than the minimum of: 1688 1689 o the RRset's TTL as received in the response; 1690 1691 o the RRSIG RR's TTL as received in the response; 1692 1693 o the value in the RRSIG RR's Original TTL field; and 1694 1695 o the difference of the RRSIG RR's Signature Expiration time and the 1696 current time. 1697 1698 1699 1700 1701 1702 Arends, et al. Standards Track [Page 31] 1703 RFC 4035 DNSSEC Protocol Modifications March 2005 1704 1705 1706 5.3.4. Authenticating a Wildcard Expanded RRset Positive Response 1707 1708 If the number of labels in an RRset's owner name is greater than the 1709 Labels field of the covering RRSIG RR, then the RRset and its 1710 covering RRSIG RR were created as a result of wildcard expansion. 1711 Once the validator has verified the signature, as described in 1712 Section 5.3, it must take additional steps to verify the non- 1713 existence of an exact match or closer wildcard match for the query. 1714 Section 5.4 discusses these steps. 1715 1716 Note that the response received by the resolver should include all 1717 NSEC RRs needed to authenticate the response (see Section 3.1.3). 1718
Section 5.4 of RFC6840 says:
When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035] suggests that "the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results". This document specifies that a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation. If a resolver adopts a more restrictive policy, there's a danger that properly signed data might unnecessarily fail validation due to cache timing issues. Furthermore, certain zone management techniques, like the Double Signature Zone Signing Key Rollover method described in Section 220.127.116.11 of [RFC6781], will not work reliably. Such a resolver is also vulnerable to malicious insertion of gibberish signatures.
1719 5.4. Authenticated Denial of Existence 1720 1721 A resolver can use authenticated NSEC RRs to prove that an RRset is 1722 not present in a signed zone. Security-aware name servers should 1723 automatically include any necessary NSEC RRs for signed zones in 1724 their responses to security-aware resolvers. 1725 1726 Denial of existence is determined by the following rules: 1727 1728 o If the requested RR name matches the owner name of an 1729 authenticated NSEC RR, then the NSEC RR's type bit map field lists 1730 all RR types present at that owner name, and a resolver can prove 1731 that the requested RR type does not exist by checking for the RR 1732 type in the bit map. If the number of labels in an authenticated 1733 NSEC RR's owner name equals the Labels field of the covering RRSIG 1734 RR, then the existence of the NSEC RR proves that wildcard 1735 expansion could not have been used to match the request. 1736 1737 o If the requested RR name would appear after an authenticated NSEC 1738 RR's owner name and before the name listed in that NSEC RR's Next 1739 Domain Name field according to the canonical DNS name order 1740 defined in [RFC4034], then no RRsets with the requested name exist 1741 in the zone. However, it is possible that a wildcard could be 1742 used to match the requested RR owner name and type, so proving 1743 that the requested RRset does not exist also requires proving that 1744 no possible wildcard RRset exists that could have been used to 1745 generate a positive response. 1746 1747 In addition, security-aware resolvers MUST authenticate the NSEC 1748 RRsets that comprise the non-existence proof as described in Section 1749 5.3. 1750 1751 To prove the non-existence of an RRset, the resolver must be able to 1752 verify both that the queried RRset does not exist and that no 1753 relevant wildcard RRset exists. Proving this may require more than 1754 1755 1756 1757 Arends, et al. Standards Track [Page 32] 1758 RFC 4035 DNSSEC Protocol Modifications March 2005 1759 1760 1761 one NSEC RRset from the zone. If the complete set of necessary NSEC 1762 RRsets is not present in a response (perhaps due to message 1763 truncation), then a security-aware resolver MUST resend the query in 1764 order to attempt to obtain the full collection of NSEC RRs necessary 1765 to verify the non-existence of the requested RRset. As with all DNS 1766 operations, however, the resolver MUST bound the work it puts into 1767 answering any particular query. 1768 1769 Since a validated NSEC RR proves the existence of both itself and its 1770 corresponding RRSIG RR, a validator MUST ignore the settings of the 1771 NSEC and RRSIG bits in an NSEC RR. 1772 1773 5.5. Resolver Behavior When Signatures Do Not Validate 1774 1775 If for whatever reason none of the RRSIGs can be validated, the 1776 response SHOULD be considered BAD. If the validation was being done 1777 to service a recursive query, the name server MUST return RCODE 2 to 1778 the originating client. However, it MUST return the full response if 1779 and only if the original query had the CD bit set. Also see Section 1780 4.7 on caching responses that do not validate. 1781 1782 5.6. Authentication Example 1783 1784 Appendix C shows an example of the authentication process. 1785 1786 6. IANA Considerations 1787 1788 [RFC4034] contains a review of the IANA considerations introduced by 1789 DNSSEC. The following are additional IANA considerations discussed 1790 in this document: 1791 1792 [RFC2535] reserved the CD and AD bits in the message header. The 1793 meaning of the AD bit was redefined in [RFC3655], and the meaning of 1794 both the CD and AD bit are restated in this document. No new bits in 1795 the DNS message header are defined in this document. 1796 1797 [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit 1798 and defined its use. The use is restated but not altered in this 1799 document. 1800 1801 7. Security Considerations 1802 1803 This document describes how the DNS security extensions use public 1804 key cryptography to sign and authenticate DNS resource record sets. 1805 Please see [RFC4033] for terminology and general security 1806 considerations related to DNSSEC; see [RFC4034] for considerations 1807 specific to the DNSSEC resource record types. 1808 1809 1810 1811 1812 Arends, et al. Standards Track [Page 33] 1813 RFC 4035 DNSSEC Protocol Modifications March 2005 1814 1815 1816 An active attacker who can set the CD bit in a DNS query message or 1817 the AD bit in a DNS response message can use these bits to defeat the 1818 protection that DNSSEC attempts to provide to security-oblivious 1819 recursive-mode resolvers. For this reason, use of these control bits 1820 by a security-aware recursive-mode resolver requires a secure 1821 channel. See Sections 3.2.2 and 4.9 for further discussion. 1822 1823 The protocol described in this document attempts to extend the 1824 benefits of DNSSEC to security-oblivious stub resolvers. However, as 1825 recovery from validation failures is likely to be specific to 1826 particular applications, the facilities that DNSSEC provides for stub 1827 resolvers may prove inadequate. Operators of security-aware 1828 recursive name servers will have to pay close attention to the 1829 behavior of the applications that use their services when choosing a 1830 local validation policy; failure to do so could easily result in the 1831 recursive name server accidentally denying service to the clients it 1832 is intended to support. 1833 1834 8. Acknowledgements 1835 1836 This document was created from the input and ideas of the members of 1837 the DNS Extensions Working Group and working group mailing list. The 1838 editors would like to express their thanks for the comments and 1839 suggestions received during the revision of these security extension 1840 specifications. Although explicitly listing everyone who has 1841 contributed during the decade in which DNSSEC has been under 1842 development would be impossible, [RFC4033] includes a list of some of 1843 the participants who were kind enough to comment on these documents. 1844 1845 9. References 1846 1847 9.1. Normative References 1848 1849 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1850 STD 13, RFC 1034, November 1987. 1851 1852 [RFC1035] Mockapetris, P., "Domain names - implementation and 1853 specification", STD 13, RFC 1035, November 1987. 1854 1855 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1856 Communication Layers", STD 3, RFC 1122, October 1989. 1857 1858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1859 Requirement Levels", BCP 14, RFC 2119, March 1997. 1860 1861 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1862 Specification", RFC 2181, July 1997. 1863 1864 1865 1866 1867 Arends, et al. Standards Track [Page 34] 1868 RFC 4035 DNSSEC Protocol Modifications March 2005 1869 1870 1871 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1872 (IPv6) Specification", RFC 2460, December 1998. 1873 1874 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 1875 2671, August 1999. 1876 1877 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 1878 2672, August 1999. 1879 1880 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 1881 3225, December 2001. 1882 1883 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 1884 message size requirements", RFC 3226, December 2001. 1885 1886 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1887 Rose, "DNS Security Introduction and Requirements", RFC 1888 4033, March 2005. 1889 1890 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1891 Rose, "Resource Records for DNS Security Extensions", RFC 1892 4034, March 2005. 1893 1894 9.2. Informative References 1895 1896 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1897 NCACHE)", RFC 2308, March 1998. 1898 1899 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 1900 Extensions", RFC 2535, March 1999. 1901 1902 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1903 Update", RFC 3007, November 2000. 1904 1905 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 1906 Authenticated Data (AD) bit", RFC 3655, November 2003. 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 Arends, et al. Standards Track [Page 35] 1923 RFC 4035 DNSSEC Protocol Modifications March 2005 1924 1925 1926 Appendix A. Signed Zone Example 1927 1928 The following example shows a (small) complete signed zone. 1929 1930 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1931 1081539377 1932 3600 1933 300 1934 3600000 1935 3600 1936 ) 1937 3600 RRSIG SOA 5 1 3600 20040509183619 ( 1938 20040409183619 38519 example. 1939 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 1940 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 1941 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 1942 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 1943 jV7j86HyQgM5e7+miRAz8V01b0I= ) 1944 3600 NS ns1.example. 1945 3600 NS ns2.example. 1946 3600 RRSIG NS 5 1 3600 20040509183619 ( 1947 20040409183619 38519 example. 1948 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd 1949 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 1950 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 1951 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 1952 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 1953 3600 MX 1 xx.example. 1954 3600 RRSIG MX 5 1 3600 20040509183619 ( 1955 20040409183619 38519 example. 1956 HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB 1957 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE 1958 VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO 1959 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM 1960 W6OISukd1EQt7a0kygkg+PEDxdI= ) 1961 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 1962 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 1963 20040409183619 38519 example. 1964 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm 1965 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V 1966 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW 1967 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm 1968 jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 1969 3600 DNSKEY 256 3 5 ( 1970 AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV 1971 rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e 1972 k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo 1973 vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI 1974 1975 1976 1977 Arends, et al. Standards Track [Page 36] 1978 RFC 4035 DNSSEC Protocol Modifications March 2005 1979 1980 1981 ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== 1982 ) 1983 3600 DNSKEY 257 3 5 ( 1984 AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl 1985 LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ 1986 syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP 1987 RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT 1988 Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== 1989 ) 1990 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 1991 20040409183619 9465 example. 1992 ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ 1993 xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ 1994 XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 1995 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY 1996 NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) 1997 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 1998 20040409183619 38519 example. 1999 eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z 2000 DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri 2001 bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp 2002 eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk 2003 7z5OXogYVaFzHKillDt3HRxHIZM= ) 2004 a.example. 3600 IN NS ns1.a.example. 2005 3600 IN NS ns2.a.example. 2006 3600 DS 57855 5 1 ( 2007 B6DCD485719ADCA18E5F3D48A2331627FDD3 2008 636B ) 2009 3600 RRSIG DS 5 2 3600 20040509183619 ( 2010 20040409183619 38519 example. 2011 oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ 2012 oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH 2013 kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD 2014 EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ 2015 Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 2016 3600 NSEC ai.example. NS DS RRSIG NSEC 2017 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2018 20040409183619 38519 example. 2019 cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba 2020 U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 2021 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I 2022 BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g 2023 sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) 2024 ns1.a.example. 3600 IN A 192.0.2.5 2025 ns2.a.example. 3600 IN A 192.0.2.6 2026 ai.example. 3600 IN A 192.0.2.9 2027 3600 RRSIG A 5 2 3600 20040509183619 ( 2028 20040409183619 38519 example. 2029 2030 2031 2032 Arends, et al. Standards Track [Page 37] 2033 RFC 4035 DNSSEC Protocol Modifications March 2005 2034 2035 2036 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B 2037 ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd 2038 hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u 2039 ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 2040 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) 2041 3600 HINFO "KLH-10" "ITS" 2042 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 2043 20040409183619 38519 example. 2044 Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l 2045 e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh 2046 ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 2047 AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw 2048 FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) 2049 3600 AAAA 2001:db8::f00:baa9 2050 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 2051 20040409183619 38519 example. 2052 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK 2053 kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 2054 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T 2055 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 2056 sZM6QjBBLmukH30+w1z3h8PUP2o= ) 2057 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC 2058 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2059 20040409183619 38519 example. 2060 QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG 2061 CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p 2062 P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN 2063 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL 2064 AhS+JOVfDI/79QtyTI0SaDWcg8U= ) 2065 b.example. 3600 IN NS ns1.b.example. 2066 3600 IN NS ns2.b.example. 2067 3600 NSEC ns1.example. NS RRSIG NSEC 2068 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2069 20040409183619 38519 example. 2070 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 2071 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS 2072 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 2073 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ 2074 vhRXgWT7OuFXldoCG6TfVFMs9xE= ) 2075 ns1.b.example. 3600 IN A 192.0.2.7 2076 ns2.b.example. 3600 IN A 192.0.2.8 2077 ns1.example. 3600 IN A 192.0.2.1 2078 3600 RRSIG A 5 2 3600 20040509183619 ( 2079 20040409183619 38519 example. 2080 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 2081 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 2082 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ 2083 +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK 2084 2085 2086 2087 Arends, et al. Standards Track [Page 38] 2088 RFC 4035 DNSSEC Protocol Modifications March 2005 2089 2090 2091 v/iVXSYC0b7mPSU+EOlknFpVECs= ) 2092 3600 NSEC ns2.example. A RRSIG NSEC 2093 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2094 20040409183619 38519 example. 2095 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 2096 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB 2097 jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq 2098 ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 2099 IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) 2100 ns2.example. 3600 IN A 192.0.2.2 2101 3600 RRSIG A 5 2 3600 20040509183619 ( 2102 20040409183619 38519 example. 2103 V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq 2104 Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu 2105 yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 2106 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq 2107 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) 2108 3600 NSEC *.w.example. A RRSIG NSEC 2109 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2110 20040409183619 38519 example. 2111 N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE 2112 VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb 2113 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH 2114 l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw 2115 Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) 2116 *.w.example. 3600 IN MX 1 ai.example. 2117 3600 RRSIG MX 5 2 3600 20040509183619 ( 2118 20040409183619 38519 example. 2119 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 2120 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc 2121 tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X 2122 TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 2123 4kX18MMR34i8lC36SR5xBni8vHI= ) 2124 3600 NSEC x.w.example. MX RRSIG NSEC 2125 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2126 20040409183619 38519 example. 2127 r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 2128 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 2129 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 2130 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 2131 s1InQ2UoIv6tJEaaKkP701j8OLA= ) 2132 x.w.example. 3600 IN MX 1 xx.example. 2133 3600 RRSIG MX 5 3 3600 20040509183619 ( 2134 20040409183619 38519 example. 2135 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 2136 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP 2137 H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I 2138 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 2139 2140 2141 2142 Arends, et al. Standards Track [Page 39] 2143 RFC 4035 DNSSEC Protocol Modifications March 2005 2144 2145 2146 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) 2147 3600 NSEC x.y.w.example. MX RRSIG NSEC 2148 3600 RRSIG NSEC 5 3 3600 20040509183619 ( 2149 20040409183619 38519 example. 2150 aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK 2151 vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E 2152 mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI 2153 NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e 2154 IjgiM8PXkBQtxPq37wDKALkyn7Q= ) 2155 x.y.w.example. 3600 IN MX 1 xx.example. 2156 3600 RRSIG MX 5 4 3600 20040509183619 ( 2157 20040409183619 38519 example. 2158 k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia 2159 t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj 2160 q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq 2161 GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb 2162 +gLcMZBnHJ326nb/TOOmrqNmQQE= ) 2163 3600 NSEC xx.example. MX RRSIG NSEC 2164 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 2165 20040409183619 38519 example. 2166 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp 2167 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg 2168 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX 2169 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr 2170 QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) 2171 xx.example. 3600 IN A 192.0.2.10 2172 3600 RRSIG A 5 2 3600 20040509183619 ( 2173 20040409183619 38519 example. 2174 kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 2175 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 2176 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y 2177 VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx 2178 kbIDV6GPPSZVusnZU6OMgdgzHV4= ) 2179 3600 HINFO "KLH-10" "TOPS-20" 2180 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 2181 20040409183619 38519 example. 2182 GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 2183 t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq 2184 BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 2185 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ 2186 RgNvuwbioFSEuv2pNlkq0goYxNY= ) 2187 3600 AAAA 2001:db8::f00:baaa 2188 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 2189 20040409183619 38519 example. 2190 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C 2191 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z 2192 ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr 2193 U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ 2194 2195 2196 2197 Arends, et al. Standards Track [Page 40] 2198 RFC 4035 DNSSEC Protocol Modifications March 2005 2199 2200 2201 xS9cL2QgW7FChw16mzlkH6/vsfs= ) 2202 3600 NSEC example. A HINFO AAAA RRSIG NSEC 2203 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2204 20040409183619 38519 example. 2205 ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY 2206 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k 2207 mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi 2208 asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W 2209 GghLahumFIpg4MO3LS/prgzVVWo= ) 2210 2211 The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA 2212 Flags indicate that each of these DNSKEY RRs is a zone key. One of 2213 these DNSKEY RRs also has the SEP flag set and has been used to sign 2214 the apex DNSKEY RRset; this is the key that should be hashed to 2215 generate a DS record to be inserted into the parent zone. The other 2216 DNSKEY is used to sign all the other RRsets in the zone. 2217 2218 The zone includes a wildcard entry, "*.w.example". Note that the 2219 name "*.w.example" is used in constructing NSEC chains, and that the 2220 RRSIG covering the "*.w.example" MX RRset has a label count of 2. 2221 2222 The zone also includes two delegations. The delegation to 2223 "b.example" includes an NS RRset, glue address records, and an NSEC 2224 RR; note that only the NSEC RRset is signed. The delegation to 2225 "a.example" provides a DS RR; note that only the NSEC and DS RRsets 2226 are signed. 2227 2228 Appendix B. Example Responses 2229 2230 The examples in this section show response messages using the signed 2231 zone example in Appendix A. 2232 2233 B.1. Answer 2234 2235 A successful query to an authoritative server. 2236 2237 ;; Header: QR AA DO RCODE=0 2238 ;; 2239 ;; Question 2240 x.w.example. IN MX 2241 2242 ;; Answer 2243 x.w.example. 3600 IN MX 1 xx.example. 2244 x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( 2245 20040409183619 38519 example. 2246 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 2247 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP 2248 H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I 2249 2250 2251 2252 Arends, et al. Standards Track [Page 41] 2253 RFC 4035 DNSSEC Protocol Modifications March 2005 2254 2255 2256 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 2257 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) 2258 2259 ;; Authority 2260 example. 3600 NS ns1.example. 2261 example. 3600 NS ns2.example. 2262 example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 2263 20040409183619 38519 example. 2264 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd 2265 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 2266 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 2267 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 2268 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 2269 2270 ;; Additional 2271 xx.example. 3600 IN A 192.0.2.10 2272 xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 2273 20040409183619 38519 example. 2274 kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 2275 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 2276 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y 2277 VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx 2278 kbIDV6GPPSZVusnZU6OMgdgzHV4= ) 2279 xx.example. 3600 AAAA 2001:db8::f00:baaa 2280 xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 2281 20040409183619 38519 example. 2282 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C 2283 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z 2284 ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr 2285 U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ 2286 xS9cL2QgW7FChw16mzlkH6/vsfs= ) 2287 ns1.example. 3600 IN A 192.0.2.1 2288 ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 2289 20040409183619 38519 example. 2290 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 2291 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 2292 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ 2293 +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK 2294 v/iVXSYC0b7mPSU+EOlknFpVECs= ) 2295 ns2.example. 3600 IN A 192.0.2.2 2296 ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 2297 20040409183619 38519 example. 2298 V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq 2299 Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu 2300 yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 2301 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq 2302 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) 2303 2304 2305 2306 2307 Arends, et al. Standards Track [Page 42] 2308 RFC 4035 DNSSEC Protocol Modifications March 2005 2309 2310 2311 B.2. Name Error 2312 2313 An authoritative name error. The NSEC RRs prove that the name does 2314 not exist and that no covering wildcard exists. 2315 2316 ;; Header: QR AA DO RCODE=3 2317 ;; 2318 ;; Question 2319 ml.example. IN A 2320 2321 ;; Answer 2322 ;; (empty) 2323 2324 ;; Authority 2325 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 2326 1081539377 2327 3600 2328 300 2329 3600000 2330 3600 2331 ) 2332 example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 2333 20040409183619 38519 example. 2334 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 2335 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 2336 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 2337 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 2338 jV7j86HyQgM5e7+miRAz8V01b0I= ) 2339 b.example. 3600 NSEC ns1.example. NS RRSIG NSEC 2340 b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2341 20040409183619 38519 example. 2342 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 2343 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS 2344 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 2345 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ 2346 vhRXgWT7OuFXldoCG6TfVFMs9xE= ) 2347 example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 2348 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 2349 20040409183619 38519 example. 2350 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm 2351 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V 2352 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW 2353 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm 2354 jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 2355 2356 ;; Additional 2357 ;; (empty) 2358 2359 2360 2361 2362 Arends, et al. Standards Track [Page 43] 2363 RFC 4035 DNSSEC Protocol Modifications March 2005 2364 2365 2366 B.3. No Data Error 2367 2368 A "no data" response. The NSEC RR proves that the name exists and 2369 that the requested RR type does not. 2370 2371 ;; Header: QR AA DO RCODE=0 2372 ;; 2373 ;; Question 2374 ns1.example. IN MX 2375 2376 ;; Answer 2377 ;; (empty) 2378 2379 ;; Authority 2380 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 2381 1081539377 2382 3600 2383 300 2384 3600000 2385 3600 2386 ) 2387 example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 2388 20040409183619 38519 example. 2389 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 2390 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 2391 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 2392 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 2393 jV7j86HyQgM5e7+miRAz8V01b0I= ) 2394 ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC 2395 ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2396 20040409183619 38519 example. 2397 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 2398 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB 2399 jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq 2400 ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 2401 IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) 2402 2403 ;; Additional 2404 ;; (empty) 2405 2406 B.4. Referral to Signed Zone 2407 2408 Referral to a signed zone. The DS RR contains the data which the 2409 resolver will need to validate the corresponding DNSKEY RR in the 2410 child zone's apex. 2411 2412 ;; Header: QR DO RCODE=0 2413 ;; 2414 2415 2416 2417 Arends, et al. Standards Track [Page 44] 2418 RFC 4035 DNSSEC Protocol Modifications March 2005 2419 2420 2421 ;; Question 2422 mc.a.example. IN MX 2423 2424 ;; Answer 2425 ;; (empty) 2426 2427 ;; Authority 2428 a.example. 3600 IN NS ns1.a.example. 2429 a.example. 3600 IN NS ns2.a.example. 2430 a.example. 3600 DS 57855 5 1 ( 2431 B6DCD485719ADCA18E5F3D48A2331627FDD3 2432 636B ) 2433 a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( 2434 20040409183619 38519 example. 2435 oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ 2436 oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH 2437 kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD 2438 EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ 2439 Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 2440 2441 ;; Additional 2442 ns1.a.example. 3600 IN A 192.0.2.5 2443 ns2.a.example. 3600 IN A 192.0.2.6 2444 2445 B.5. Referral to Unsigned Zone 2446 2447 Referral to an unsigned zone. The NSEC RR proves that no DS RR for 2448 this delegation exists in the parent zone. 2449 2450 ;; Header: QR DO RCODE=0 2451 ;; 2452 ;; Question 2453 mc.b.example. IN MX 2454 2455 ;; Answer 2456 ;; (empty) 2457 2458 ;; Authority 2459 b.example. 3600 IN NS ns1.b.example. 2460 b.example. 3600 IN NS ns2.b.example. 2461 b.example. 3600 NSEC ns1.example. NS RRSIG NSEC 2462 b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2463 20040409183619 38519 example. 2464 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 2465 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS 2466 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 2467 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ 2468 vhRXgWT7OuFXldoCG6TfVFMs9xE= ) 2469 2470 2471 2472 Arends, et al. Standards Track [Page 45] 2473 RFC 4035 DNSSEC Protocol Modifications March 2005 2474 2475 2476 ;; Additional 2477 ns1.b.example. 3600 IN A 192.0.2.7 2478 ns2.b.example. 3600 IN A 192.0.2.8 2479 2480 B.6. Wildcard Expansion 2481 2482 A successful query that was answered via wildcard expansion. The 2483 label count in the answer's RRSIG RR indicates that a wildcard RRset 2484 was expanded to produce this response, and the NSEC RR proves that no 2485 closer match exists in the zone. 2486 2487 ;; Header: QR AA DO RCODE=0 2488 ;; 2489 ;; Question 2490 a.z.w.example. IN MX 2491 2492 ;; Answer 2493 a.z.w.example. 3600 IN MX 1 ai.example. 2494 a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 2495 20040409183619 38519 example. 2496 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 2497 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc 2498 tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X 2499 TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 2500 4kX18MMR34i8lC36SR5xBni8vHI= ) 2501 2502 ;; Authority 2503 example. 3600 NS ns1.example. 2504 example. 3600 NS ns2.example. 2505 example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 2506 20040409183619 38519 example. 2507 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd 2508 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 2509 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 2510 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 2511 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 2512 x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC 2513 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 2514 20040409183619 38519 example. 2515 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp 2516 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg 2517 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX 2518 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr 2519 QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) 2520 2521 ;; Additional 2522 ai.example. 3600 IN A 192.0.2.9 2523 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 2524 2525 2526 2527 Arends, et al. Standards Track [Page 46] 2528 RFC 4035 DNSSEC Protocol Modifications March 2005 2529 2530 2531 20040409183619 38519 example. 2532 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B 2533 ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd 2534 hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u 2535 ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 2536 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) 2537 ai.example. 3600 AAAA 2001:db8::f00:baa9 2538 ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 2539 20040409183619 38519 example. 2540 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK 2541 kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 2542 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T 2543 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 2544 sZM6QjBBLmukH30+w1z3h8PUP2o= ) 2545 2546 B.7. Wildcard No Data Error 2547 2548 A "no data" response for a name covered by a wildcard. The NSEC RRs 2549 prove that the matching wildcard name does not have any RRs of the 2550 requested type and that no closer match exists in the zone. 2551 2552 ;; Header: QR AA DO RCODE=0 2553 ;; 2554 ;; Question 2555 a.z.w.example. IN AAAA 2556 2557 ;; Answer 2558 ;; (empty) 2559 2560 ;; Authority 2561 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 2562 1081539377 2563 3600 2564 300 2565 3600000 2566 3600 2567 ) 2568 example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 2569 20040409183619 38519 example. 2570 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 2571 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 2572 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 2573 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 2574 jV7j86HyQgM5e7+miRAz8V01b0I= ) 2575 x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC 2576 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 2577 20040409183619 38519 example. 2578 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp 2579 2580 2581 2582 Arends, et al. Standards Track [Page 47] 2583 RFC 4035 DNSSEC Protocol Modifications March 2005 2584 2585 2586 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg 2587 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX 2588 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr 2589 QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) 2590 *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC 2591 *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 2592 20040409183619 38519 example. 2593 r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 2594 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 2595 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 2596 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 2597 s1InQ2UoIv6tJEaaKkP701j8OLA= ) 2598 2599 ;; Additional 2600 ;; (empty) 2601 2602 B.8. DS Child Zone No Data Error 2603 2604 A "no data" response for a QTYPE=DS query that was mistakenly sent to 2605 a name server for the child zone. 2606 2607 ;; Header: QR AA DO RCODE=0 2608 ;; 2609 ;; Question 2610 example. IN DS 2611 2612 ;; Answer 2613 ;; (empty) 2614 2615 ;; Authority 2616 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 2617 1081539377 2618 3600 2619 300 2620 3600000 2621 3600 2622 ) 2623 example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 2624 20040409183619 38519 example. 2625 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 2626 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF 2627 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW 2628 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB 2629 jV7j86HyQgM5e7+miRAz8V01b0I= ) 2630 example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 2631 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 2632 20040409183619 38519 example. 2633 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm 2634 2635 2636 2637 Arends, et al. Standards Track [Page 48] 2638 RFC 4035 DNSSEC Protocol Modifications March 2005 2639 2640 2641 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V 2642 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW 2643 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm 2644 jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 2645 2646 ;; Additional 2647 ;; (empty) 2648 2649 Appendix C. Authentication Examples 2650 2651 The examples in this section show how the response messages in 2652 Appendix B are authenticated. 2653
Section 4.1 of RFC6840 says:
Section 5.4 of [RFC4035] under-specifies the algorithm for checking nonexistence proofs. In particular, the algorithm as presented would allow a validator to interpret an NSEC or NSEC3 RR from an ancestor zone as proving the nonexistence of an RR in a child zone. An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: o the NS bit set, o the Start of Authority (SOA) bit clear, and o a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR. Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence of any RRs below that zone cut, which include all RRs at that (original) owner name other than DS RRs, and all RRs below that owner name regardless of type. Similarly, the algorithm would also allow an NSEC RR at the same owner name as a DNAME RR, or an NSEC3 RR at the same original owner name as a DNAME, to prove the nonexistence of names beneath that DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's (original) owner name.
2654 C.1. Authenticating an Answer 2655 2656 The query in Appendix B.1 returned an MX RRset for "x.w.example.com". 2657 The corresponding RRSIG indicates that the MX RRset was signed by an 2658 "example" DNSKEY with algorithm 5 and key tag 38519. The resolver 2659 needs the corresponding DNSKEY RR in order to authenticate this 2660 answer. The discussion below describes how a resolver might obtain 2661 this DNSKEY RR. 2662 2663 The RRSIG indicates the original TTL of the MX RRset was 3600, and, 2664 for the purpose of authentication, the current TTL is replaced by 2665 3600. The RRSIG labels field value of 3 indicates that the answer 2666 was not the result of wildcard expansion. The "x.w.example.com" MX 2667 RRset is placed in canonical form, and, assuming the current time 2668 falls between the signature inception and expiration dates, the 2669 signature is authenticated. 2670 2671 C.1.1. Authenticating the Example DNSKEY RR 2672 2673 This example shows the logical authentication process that starts 2674 from the a configured root DNSKEY (or DS RR) and moves down the tree 2675 to authenticate the desired "example" DNSKEY RR. Note that the 2676 logical order is presented for clarity. An implementation may choose 2677 to construct the authentication as referrals are received or to 2678 construct the authentication chain only after all RRsets have been 2679 obtained, or in any other combination it sees fit. The example here 2680 demonstrates only the logical process and does not dictate any 2681 implementation rules. 2682 2683 We assume the resolver starts with a configured DNSKEY RR for the 2684 root zone (or a configured DS RR for the root zone). The resolver 2685 checks whether this configured DNSKEY RR is present in the root 2686 DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root 2687 DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY 2688 RRset, and whether the signature lifetime is valid. If all these 2689 2690 2691 2692 Arends, et al. Standards Track [Page 49] 2693 RFC 4035 DNSSEC Protocol Modifications March 2005 2694 2695 2696 conditions are met, all keys in the DNSKEY RRset are considered 2697 authenticated. The resolver then uses one (or more) of the root 2698 DNSKEY RRs to authenticate the "example" DS RRset. Note that the 2699 resolver may have to query the root zone to obtain the root DNSKEY 2700 RRset or "example" DS RRset. 2701 2702 Once the DS RRset has been authenticated using the root DNSKEY, the 2703 resolver checks the "example" DNSKEY RRset for some "example" DNSKEY 2704 RR that matches one of the authenticated "example" DS RRs. If such a 2705 matching "example" DNSKEY is found, the resolver checks whether this 2706 DNSKEY RR has signed the "example" DNSKEY RRset and the signature 2707 lifetime is valid. If these conditions are met, all keys in the 2708 "example" DNSKEY RRset are considered authenticated. 2709 2710 Finally, the resolver checks that some DNSKEY RR in the "example" 2711 DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This 2712 DNSKEY is used to authenticate the RRSIG included in the response. 2713 If multiple "example" DNSKEY RRs match this algorithm and key tag, 2714 then each DNSKEY RR is tried, and the answer is authenticated if any 2715 of the matching DNSKEY RRs validate the signature as described above. 2716 2717 C.2. Name Error 2718 2719 The query in Appendix B.2 returned NSEC RRs that prove that the 2720 requested data does not exist and no wildcard applies. The negative 2721 reply is authenticated by verifying both NSEC RRs. The NSEC RRs are 2722 authenticated in a manner identical to that of the MX RRset discussed 2723 above. 2724 2725 C.3. No Data Error 2726 2727 The query in Appendix B.3 returned an NSEC RR that proves that the 2728 requested name exists, but the requested RR type does not exist. The 2729 negative reply is authenticated by verifying the NSEC RR. The NSEC 2730 RR is authenticated in a manner identical to that of the MX RRset 2731 discussed above. 2732 2733 C.4. Referral to Signed Zone 2734 2735 The query in Appendix B.4 returned a referral to the signed 2736 "a.example." zone. The DS RR is authenticated in a manner identical 2737 to that of the MX RRset discussed above. This DS RR is used to 2738 authenticate the "a.example" DNSKEY RRset. 2739 2740 Once the "a.example" DS RRset has been authenticated using the 2741 "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset 2742 for some "a.example" DNSKEY RR that matches the DS RR. If such a 2743 matching "a.example" DNSKEY is found, the resolver checks whether 2744 2745 2746 2747 Arends, et al. Standards Track [Page 50] 2748 RFC 4035 DNSSEC Protocol Modifications March 2005 2749 2750 2751 this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether 2752 the signature lifetime is valid. If all these conditions are met, 2753 all keys in the "a.example" DNSKEY RRset are considered 2754 authenticated. 2755 2756 C.5. Referral to Unsigned Zone 2757 2758 The query in Appendix B.5 returned a referral to an unsigned 2759 "b.example." zone. The NSEC proves that no authentication leads from 2760 "example" to "b.example", and the NSEC RR is authenticated in a 2761 manner identical to that of the MX RRset discussed above. 2762
Section 6.3 of RFC6840 says:
The text in Appendix C.1 of [RFC4035] refers to the examples in Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example". This is painfully obvious in the second paragraph where it states that the RRSIG labels field value of 3 indicates that the answer was not the result of wildcard expansion. This is true for "x.w.example" but not for "x.w.example.com", which of course has a label count of 4 (antithetically, a label count of 3 would imply the answer was the result of a wildcard expansion).
2763 C.6. Wildcard Expansion 2764 2765 The query in Appendix B.6 returned an answer that was produced as a 2766 result of wildcard expansion. The answer section contains a wildcard 2767 RRset expanded as it would be in a traditional DNS response, and the 2768 corresponding RRSIG indicates that the expanded wildcard MX RRset was 2769 signed by an "example" DNSKEY with algorithm 5 and key tag 38519. 2770 The RRSIG indicates that the original TTL of the MX RRset was 3600, 2771 and, for the purpose of authentication, the current TTL is replaced 2772 by 3600. The RRSIG labels field value of 2 indicates that the answer 2773 is the result of wildcard expansion, as the "a.z.w.example" name 2774 contains 4 labels. The name "a.z.w.w.example" is replaced by 2775 "*.w.example", the MX RRset is placed in canonical form, and, 2776 assuming that the current time falls between the signature inception 2777 and expiration dates, the signature is authenticated. 2778 2779 The NSEC proves that no closer match (exact or closer wildcard) could 2780 have been used to answer this query, and the NSEC RR must also be 2781 authenticated before the answer is considered valid. 2782 2783 C.7. Wildcard No Data Error 2784 2785 The query in Appendix B.7 returned NSEC RRs that prove that the 2786 requested data does not exist and no wildcard applies. The negative 2787 reply is authenticated by verifying both NSEC RRs. 2788
Section 6.3 of RFC6840 says:
The first paragraph of Appendix C.6 of [RFC4035] also has a minor error: the reference to "a.z.w.w.example" should instead be "a.z.w.example", as in the previous line.
2789 C.8. DS Child Zone No Data Error 2790 2791 The query in Appendix B.8 returned NSEC RRs that shows the requested 2792 was answered by a child server ("example" server). The NSEC RR 2793 indicates the presence of an SOA RR, showing that the answer is from 2794 the child . Queries for the "example" DS RRset should be sent to the 2795 parent servers ("root" servers). 2796 2797 2798 2799 2800 2801 2802 Arends, et al. Standards Track [Page 51] 2803 RFC 4035 DNSSEC Protocol Modifications March 2005 2804 2805 2806 Authors' Addresses 2807 2808 Roy Arends 2809 Telematica Instituut 2810 Brouwerijstraat 1 2811 7523 XC Enschede 2812 NL 2813 2814 EMail: email@example.com 2815 2816 2817 Rob Austein 2818 Internet Systems Consortium 2819 950 Charter Street 2820 Redwood City, CA 94063 2821 USA 2822 2823 EMail: firstname.lastname@example.org 2824 2825 2826 Matt Larson 2827 VeriSign, Inc. 2828 21345 Ridgetop Circle 2829 Dulles, VA 20166-6503 2830 USA 2831 2832 EMail: email@example.com 2833 2834 2835 Dan Massey 2836 Colorado State University 2837 Department of Computer Science 2838 Fort Collins, CO 80523-1873 2839 2840 EMail: firstname.lastname@example.org 2841 2842 2843 Scott Rose 2844 National Institute for Standards and Technology 2845 100 Bureau Drive 2846 Gaithersburg, MD 20899-8920 2847 USA 2848 2849 EMail: email@example.com 2850 2851 2852 2853 2854 2855 2856 2857 Arends, et al. Standards Track [Page 52] 2858 RFC 4035 DNSSEC Protocol Modifications March 2005 2859 2860 2861 Full Copyright Statement 2862 2863 Copyright (C) The Internet Society (2005). 2864 2865 This document is subject to the rights, licenses and restrictions 2866 contained in BCP 78, and except as set forth therein, the authors 2867 retain all their rights. 2868 2869 This document and the information contained herein are provided on an 2870 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2871 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2872 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2873 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2874 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2875 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2876 2877 Intellectual Property 2878 2879 The IETF takes no position regarding the validity or scope of any 2880 Intellectual Property Rights or other rights that might be claimed to 2881 pertain to the implementation or use of the technology described in 2882 this document or the extent to which any license under such rights 2883 might or might not be available; nor does it represent that it has 2884 made any independent effort to identify any such rights. Information 2885 on the procedures with respect to rights in RFC documents can be 2886 found in BCP 78 and BCP 79. 2887 2888 Copies of IPR disclosures made to the IETF Secretariat and any 2889 assurances of licenses to be made available, or the result of an 2890 attempt made to obtain a general license or permission for the use of 2891 such proprietary rights by implementers or users of this 2892 specification can be obtained from the IETF on-line IPR repository at 2893 http://www.ietf.org/ipr. 2894 2895 The IETF invites any interested party to bring to its attention any 2896 copyrights, patents or patent applications, or other proprietary 2897 rights that may cover technology that may be required to implement 2898 this standard. Please address the information to the IETF at ietf- 2899 firstname.lastname@example.org. 2900 2901 Acknowledgement 2902 2903 Funding for the RFC Editor function is currently provided by the 2904 Internet Society. 2905 2906 2907 2908 2909 2910 2911 2912 Arends, et al. Standards Track [Page 53] 2913
Section 6.1 of RFC6840 says:
Appendix C.8 of [RFC4035] discusses sending DS queries to the servers for a parent zone but does not state how to find those servers. Specific instructions can be found in Section 4.2 of [RFC4035].