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