idnits 2.17.1 draft-ietf-dnsext-dnssec-intro-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 952. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 10, 2004) is 7110 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) == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-06 == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-08 ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2538 (Obsoleted by RFC 4398) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3008 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3090 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3655 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3757 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3845 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions R. Arends 3 Internet-Draft Telematica Instituut 4 Expires: April 10, 2005 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 October 10, 2004 14 DNS Security Introduction and Requirements 15 draft-ietf-dnsext-dnssec-intro-13 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 10, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). 48 Abstract 49 The Domain Name System Security Extensions (DNSSEC) add data origin 50 authentication and data integrity to the Domain Name System. This 51 document introduces these extensions, and describes their 52 capabilities and limitations. This document also discusses the 53 services that the DNS security extensions do and do not provide. 54 Last, this document describes the interrelationships between the 55 group of documents that collectively describe DNSSEC. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 61 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 62 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 63 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 10 64 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 65 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 66 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 67 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 68 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 70 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 71 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 72 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 74 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 75 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 76 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 78 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 80 Intellectual Property and Copyright Statements . . . . . . . . 26 82 1. Introduction 84 This document introduces the Domain Name System Security Extensions 85 (DNSSEC). This document and its two companion documents 86 ([I-D.ietf-dnsext-dnssec-records] and 87 [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the 88 security extensions defined in [RFC2535] and its predecessors. These 89 security extensions consist of a set of new resource record types and 90 modifications to the existing DNS protocol ([RFC1035]). The new 91 records and protocol modifications are not fully described in this 92 document, but are described in a family of documents outlined in 93 Section 10. Section 3 and Section 4 describe the capabilities and 94 limitations of the security extensions in greater detail. Section 5 95 discusses the scope of the document set. Section 6, Section 7, 96 Section 8, and Section 9 discuss the effect that these security 97 extensions will have on resolvers, stub resolvers, zones and name 98 servers. 100 This document and its two companions obsolete [RFC2535], [RFC3008], 101 [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and 102 [RFC3845]. This document set also updates, but does not obsolete, 103 [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], 104 [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with 105 DNSSEC. 107 The DNS security extensions provide origin authentication and 108 integrity protection for DNS data, as well as a means of public key 109 distribution. These extensions do not provide confidentiality. 111 2. Definitions of Important DNSSEC Terms 113 This section defines a number of terms used in this document set. 114 Since this is intended to be useful as a reference while reading the 115 rest of the document set, first-time readers may wish to skim this 116 section quickly, read the rest of this document, then come back to 117 this section. 119 Authentication Chain: An alternating sequence of DNS public key 120 (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of 121 signed data, with each link in the chain vouching for the next. A 122 DNSKEY RR is used to verify the signature covering a DS RR and 123 allows the DS RR to be authenticated. The DS RR contains a hash 124 of another DNSKEY RR and this new DNSKEY RR is authenticated by 125 matching the hash in the DS RR. This new DNSKEY RR in turn 126 authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in 127 this set may be used to authenticate another DS RR and so forth 128 until the chain finally ends with a DNSKEY RR whose corresponding 129 private key signs the desired DNS data. For example, the root 130 DNSKEY RRset can be used to authenticate the DS RRset for 131 "example." The "example." DS RRset contains a hash that matches 132 some "example." DNSKEY, and this DNSKEY's corresponding private 133 key signs the "example." DNSKEY RRset. Private key counterparts 134 of the "example." DNSKEY RRset sign data records such as 135 "www.example." as well as DS RRs for delegations such as 136 "subzone.example." 138 Authentication Key: A public key that a security-aware resolver has 139 verified and can therefore use to authenticate data. A 140 security-aware resolver can obtain authentication keys in three 141 ways. First, the resolver is generally configured to know about 142 at least one public key; this configured data is usually either 143 the public key itself or a hash of the public key as found in the 144 DS RR (see "trust anchor"). Second, the resolver may use an 145 authenticated public key to verify a DS RR and the DNSKEY RR to 146 which the DS RR refers. Third, the resolver may be able to 147 determine that a new public key has been signed by the private key 148 corresponding to another public key which the resolver has 149 verified. Note that the resolver must always be guided by local 150 policy when deciding whether to authenticate a new public key, 151 even if the local policy is simply to authenticate any new public 152 key for which the resolver is able verify the signature. 154 Authoritative RRset: Within the context of a particular zone, an 155 RRset is "authoritative" if and only if the owner name of the 156 RRset lies within the subset of the name space that is at or below 157 the zone apex and at or above the cuts that separate the zone from 158 its children, if any. All RRsets at the zone apex are 159 authoritative, except for certain RRsets at this domain name that, 160 if present, belong to this zone's parent. These RRset could 161 include a DS RRset, the NSEC RRset referencing this DS RRset (the 162 "parental NSEC"), and RRSIG RRs associated with these RRsets, all 163 of which are authoritative in the parent zone. Similarly, if this 164 zone contains any delegation points, only the parental NSEC RRset, 165 DS RRsets, and any RRSIG RRs associated with these these RRsets 166 are authoritative for this zone. 168 Delegation Point: Term used to describe the name at the parental side 169 of a zone cut. That is, the delegation point for "foo.example" 170 would be the foo.example node in the "example" zone (as opposed to 171 the zone apex of the "foo.example" zone). See also: zone apex. 173 Island of Security: Term used to describe a signed, delegated zone 174 that does not have an authentication chain from its delegating 175 parent. That is, there is no DS RR containing a hash of a DNSKEY 176 RR for the island in its delegating parent zone (see 177 [I-D.ietf-dnsext-dnssec-records]). An island of security is 178 served by security-aware name servers and may provide 179 authentication chains to any delegated child zones. Responses 180 from an island of security or its descendents can only be 181 authenticated if its authentication keys can be authenticated by 182 some trusted means out of band from the DNS protocol. 184 Key Signing Key (KSK): An authentication key that corresponds to a 185 private key used to sign one or more other authentication keys for 186 a given zone. Typically, the private key corresponding to a key 187 signing key will sign a zone signing key, which in turn has a 188 corresponding private key which will sign other zone data. Local 189 policy may require the zone signing key to be changed frequently, 190 while the key signing key may have a longer validity period in 191 order to provide a more stable secure entry point into the zone. 192 Designating an authentication key as a key signing key is purely 193 an operational issue: DNSSEC validation does not distinguish 194 between key signing keys and other DNSSEC authentication keys, and 195 it is possible to use a single key as both a key signing key and a 196 zone signing key. Key signing keys are discussed in more detail 197 in [RFC3757]. Also see: zone signing key. 199 Non-Validating Security-Aware Stub Resolver: A security-aware stub 200 resolver which trusts one or more security-aware recursive name 201 servers to perform most of the tasks discussed in this document 202 set on its behalf. In particular, a non-validating security-aware 203 stub resolver is an entity which sends DNS queries, receives DNS 204 responses, and is capable of establishing an appropriately secured 205 channel to a security-aware recursive name server which will 206 provide these services on behalf of the security-aware stub 207 resolver. See also: security-aware stub resolver, validating 208 security-aware stub resolver. 210 Non-Validating Stub Resolver: A less tedious term for a 211 non-validating security-aware stub resolver. 213 Security-Aware Name Server: An entity acting in the role of a name 214 server (defined in section 2.4 of [RFC1034]) that understands the 215 DNS security extensions defined in this document set. In 216 particular, a security-aware name server is an entity which 217 receives DNS queries, sends DNS responses, supports the EDNS0 218 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and 219 supports the RR types and message header bits defined in this 220 document set. 222 Security-Aware Recursive Name Server: An entity which acts in both 223 the security-aware name server and security-aware resolver roles. 224 A more cumbersome equivalent phrase would be "a security-aware 225 name server which offers recursive service". 227 Security-Aware Resolver: An entity acting in the role of a resolver 228 (defined in section 2.4 of [RFC1034]) which understands the DNS 229 security extensions defined in this document set. In particular, 230 a security-aware resolver is an entity which sends DNS queries, 231 receives DNS responses, supports the EDNS0 ([RFC2671]) message 232 size extension and the DO bit ([RFC3225]), and is capable of using 233 the RR types and message header bits defined in this document set 234 to provide DNSSEC services. 236 Security-Aware Stub Resolver: An entity acting in the role of a stub 237 resolver (defined in section 5.3.1 of [RFC1034]) which has enough 238 of an understanding the DNS security extensions defined in this 239 document set to provide additional services not available from a 240 security-oblivious stub resolver. Security-aware stub resolvers 241 may be either "validating" or "non-validating" depending on 242 whether the stub resolver attempts to verify DNSSEC signatures on 243 its own or trusts a friendly security-aware name server to do so. 244 See also: validating stub resolver, non-validating stub resolver. 246 Security-Oblivious : An that is not 247 "security-aware". 249 Signed Zone: A zone whose RRsets are signed and which contains 250 properly constructed DNSKEY, Resource Record Signature (RRSIG), 251 Next Secure (NSEC) and (optionally) DS records. 253 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A 254 validating security-aware resolver uses this public key or hash as 255 a starting point for building the authentication chain to a signed 256 DNS response. In general, a validating resolver will need to 257 obtain the initial values of its trust anchors via some secure or 258 trusted means outside the DNS protocol. Presence of a trust 259 anchor also implies that the resolver should expect the zone to 260 which the trust anchor points to be signed. 262 Unsigned Zone: A zone that is not signed. 264 Validating Security-Aware Stub Resolver: A security-aware resolver 265 that sends queries in recursive mode but which performs signature 266 validation on its own rather than just blindly trusting an 267 upstream security-aware recursive name server. See also: 268 security-aware stub resolver, non-validating security-aware stub 269 resolver. 271 Validating Stub Resolver: A less tedious term for a validating 272 security-aware stub resolver. 274 Zone Apex: Term used to describe the name at the child's side of a 275 zone cut. See also: delegation point. 277 Zone Signing Key (ZSK): An authentication key that corresponds to a 278 private key used to sign a zone. Typically a zone signing key 279 will be part of the same DNSKEY RRset as the key signing key whose 280 corresponding private key signs this DNSKEY RRset, but the zone 281 signing key is used for a slightly different purpose, and may 282 differ from the key signing key in other ways, such as validity 283 lifetime. Designating an authentication key as a zone signing key 284 is purely an operational issue: DNSSEC validation does not 285 distinguish between zone signing keys and other DNSSEC 286 authentication keys, and it is possible to use a single key as 287 both a key signing key and a zone signing key. See also: key 288 signing key. 290 3. Services Provided by DNS Security 292 The Domain Name System (DNS) security extensions provide origin 293 authentication and integrity assurance services for DNS data, 294 including mechanisms for authenticated denial of existence of DNS 295 data. These mechanisms are described below. 297 These mechanisms require changes to the DNS protocol. DNSSEC adds 298 four new resource record types: Resource Record Signature, DNS Public 299 Key, Delegation Signer, and Next Secure (RRSIG, DNSKEY, DS and NSEC) 300 and two new message header bits: Checking Disabled and Authenticated 301 Data (CD and AD). In order to support the larger DNS message sizes 302 that result from adding the DNSSEC RRs, DNSSEC also requires EDNS0 303 support ([RFC2671]). Finally, DNSSEC requires support for the DNSSEC 304 OK (DO) EDNS header bit ([RFC3225]), so that a security-aware 305 resolver can indicate in its queries that it wishes to receive DNSSEC 306 RRs in response messages. 308 These services protect against most of the threats to the Domain Name 309 System described in [RFC3833]. Please see Section 12 for a 310 discussion of the limitations of these extensions. 312 3.1 Data Origin Authentication and Data Integrity 314 DNSSEC provides authentication by associating cryptographically 315 generated digital signatures with DNS RRsets. These digital 316 signatures are stored in a new resource record, the RRSIG record. 317 Typically, there will be a single private key that signs a zone's 318 data, but multiple keys are possible: for example, there may be keys 319 for each of several different digital signature algorithms. If a 320 security-aware resolver reliably learns a zone's public key, it can 321 authenticate that zone's signed data. An important DNSSEC concept is 322 that the key that signs a zone's data is associated with the zone 323 itself and not with the zone's authoritative name servers (public 324 keys for DNS transaction authentication mechanisms may also appear in 325 zones, as described in [RFC2931], but DNSSEC itself is concerned with 326 object security of DNS data, not channel security of DNS 327 transactions. The keys associated with transaction security may be 328 stored in different RR types. See [RFC3755] for details.). 330 A security-aware resolver can learn a zone's public key either by 331 having a trust anchor configured into the resolver or by normal DNS 332 resolution. To allow the latter, public keys are stored in a new 333 type of resource record, the DNSKEY RR. Note that the private keys 334 used to sign zone data must be kept secure, and should be stored 335 offline when practical to do so. To discover a public key reliably 336 via DNS resolution, the target key itself needs to be signed by 337 either a configured authentication key or another key that has been 338 authenticated previously. Security-aware resolvers authenticate zone 339 information by forming an authentication chain from a newly learned 340 public key back to a previously known authentication public key, 341 which in turn either has been configured into the resolver or must 342 have been learned and verified previously. Therefore, the resolver 343 must be configured with at least one trust anchor. 345 If the configured trust anchor is a zone signing key, then it will 346 authenticate the associated zone; if the configured key is a key 347 signing key, it will authenticate a zone signing key. If the 348 configured trust anchor is the hash of a key rather than the key 349 itself, the resolver may need to obtain the key via a DNS query. To 350 help security-aware resolvers establish this authentication chain, 351 security-aware name servers attempt to send the signature(s) needed 352 to authenticate a zone's public key(s) in the DNS reply message along 353 with the public key itself, provided there is space available in the 354 message. 356 The Delegation Signer (DS) RR type simplifies some of the 357 administrative tasks involved in signing delegations across 358 organizational boundaries. The DS RRset resides at a delegation 359 point in a parent zone and indicates the public key(s) corresponding 360 to the private key(s) used to self-sign the DNSKEY RRset at the 361 delegated child zone's apex. The administrator of the child zone, in 362 turn, uses the private key(s) corresponding to one or more of the 363 public keys in this DNSKEY RRset to sign the child zone's data. The 364 typical authentication chain is therefore 365 DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more 366 DS->DNSKEY subchains. DNSSEC permits more complex authentication 367 chains, such as additional layers of DNSKEY RRs signing other DNSKEY 368 RRs within a zone. 370 A security-aware resolver normally constructs this authentication 371 chain from the root of the DNS hierarchy down to the leaf zones based 372 on configured knowledge of the public key for the root. Local 373 policy, however, may also allow a security-aware resolver to use one 374 or more configured public keys (or hashes of public keys) other than 375 the root public key, or may not provide configured knowledge of the 376 root public key, or may prevent the resolver from using particular 377 public keys for arbitrary reasons even if those public keys are 378 properly signed with verifiable signatures. DNSSEC provides 379 mechanisms by which a security-aware resolver can determine whether 380 an RRset's signature is "valid" within the meaning of DNSSEC. In the 381 final analysis however, authenticating both DNS keys and data is a 382 matter of local policy, which may extend or even override the 383 protocol extensions defined in this document set. See Section 5 for 384 further discussion. 386 3.2 Authenticating Name and Type Non-Existence 388 The security mechanism described in Section 3.1 only provides a way 389 to sign existing RRsets in a zone. The problem of providing negative 390 responses with the same level of authentication and integrity 391 requires the use of another new resource record type, the NSEC 392 record. The NSEC record allows a security-aware resolver to 393 authenticate a negative reply for either name or type non-existence 394 via the same mechanisms used to authenticate other DNS replies. Use 395 of NSEC records requires a canonical representation and ordering for 396 domain names in zones. Chains of NSEC records explicitly describe 397 the gaps, or "empty space", between domain names in a zone, as well 398 as listing the types of RRsets present at existing names. Each NSEC 399 record is signed and authenticated using the mechanisms described in 400 Section 3.1. 402 4. Services Not Provided by DNS Security 404 DNS was originally designed with the assumptions that the DNS will 405 return the same answer to any given query regardless of who may have 406 issued the query, and that all data in the DNS is thus visible. 407 Accordingly, DNSSEC is not designed to provide confidentiality, 408 access control lists, or other means of differentiating between 409 inquirers. 411 DNSSEC provides no protection against denial of service attacks. 412 Security-aware resolvers and security-aware name servers are 413 vulnerable to an additional class of denial of service attacks based 414 on cryptographic operations. Please see Section 12 for details. 416 The DNS security extensions provide data and origin authentication 417 for DNS data. The mechanisms outlined above are not designed to 418 protect operations such as zone transfers and dynamic update 419 ([RFC2136], [RFC3007]). Message authentication schemes described in 420 [RFC2845] and [RFC2931] address security operations that pertain to 421 these transactions. 423 5. Scope of the DNSSEC Document Set and Last Hop Issues 425 The specification in this document set defines the behavior for zone 426 signers and security-aware name servers and resolvers in such a way 427 that the validating entities can unambiguously determine the state of 428 the data. 430 A validating resolver can determine these 4 states: 432 Secure: The validating resolver has a trust anchor, a chain of trust 433 and is able to verify all the signatures in the response. 435 Insecure: The validating resolver has a trust anchor, a chain of 436 trust, and, at some delegation point, signed proof of the 437 non-existence of a DS record. That indicates that subsequent 438 branches in the tree are provably insecure. A validating resolver 439 may have local policy to mark parts of the domain space as 440 insecure. 442 Bogus: The validating resolver has a trust anchor and there is a 443 secure delegation which is indicating that subsidiary data will be 444 signed, but the response fails to validate due to one or more 445 reasons: missing signatures, expired signatures, signatures with 446 unsupported algorithms, data missing which the relevant NSEC RR 447 says should be present, and so forth. 449 Indeterminate: There is no trust anchor which would indicate that a 450 specific portion of the tree is secure. This is the default 451 operation mode. 453 This specification only defines how security aware name servers can 454 signal non-validating stub resolvers that data was found to be bogus 455 (using RCODE=2, "Server Failure" -- see 456 [I-D.ietf-dnsext-dnssec-protocol]). 458 There is a mechanism for security aware name servers to signal 459 security-aware stub resolvers that data was found to be secure (using 460 the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). 462 This specification does not define a format for communicating why 463 responses were found to be bogus or marked as insecure. The current 464 signaling mechanism does not distinguish between indeterminate and 465 insecure. 467 A method for signaling advanced error codes and policy between a 468 security aware stub resolver and security aware recursive nameservers 469 is a topic for future work, as is the interface between a security 470 aware resolver and the applications that use it. Note, however, that 471 the lack of the specification of such communication does not prohibit 472 deployment of signed zones or the deployment of security aware 473 recursive name servers that prohibit propagation of bogus data to the 474 applications. 476 6. Resolver Considerations 478 A security-aware resolver needs to be able to perform cryptographic 479 functions necessary to verify digital signatures using at least the 480 mandatory-to-implement algorithm(s). Security-aware resolvers must 481 also be capable of forming an authentication chain from a newly 482 learned zone back to an authentication key, as described above. This 483 process might require additional queries to intermediate DNS zones to 484 obtain necessary DNSKEY, DS and RRSIG records. A security-aware 485 resolver should be configured with at least one trust anchor as the 486 starting point from which it will attempt to establish authentication 487 chains. 489 If a security-aware resolver is separated from the relevant 490 authoritative name servers by a recursive name server or by any sort 491 of intermediary device which acts as a proxy for DNS, and if the 492 recursive name server or intermediary device is not security-aware, 493 the security-aware resolver may not be capable of operating in a 494 secure mode. For example, if a security-aware resolver's packets are 495 routed through a network address translation (NAT) device that 496 includes a DNS proxy which is not security-aware, the security-aware 497 resolver may find it difficult or impossible to obtain or validate 498 signed DNS data. The security-aware resolver may have a particularly 499 difficult time obtaining DS RRs in such a case, since DS RRs do not 500 follow the usual DNS rules for ownership of RRs at zone cuts. Note 501 that this problem is not specific to NATs -- any security-oblivious 502 DNS software of any kind between the security-aware resolver and the 503 authoritative name servers will interfere with DNSSEC. 505 If a security-aware resolver must rely on an unsigned zone or a name 506 server that is not security aware, the resolver may not be able to 507 validate DNS responses, and will need a local policy on whether to 508 accept unverified responses. 510 A security-aware resolver should take a signature's validation period 511 into consideration when determining the TTL of data in its cache, to 512 avoid caching signed data beyond the validity period of the 513 signature, but should also allow for the possibility that the 514 security-aware resolver's own clock is wrong. Thus, a security-aware 515 resolver which is part of a security-aware recursive name server will 516 need to pay careful attention to the DNSSEC "checking disabled" (CD) 517 bit ([I-D.ietf-dnsext-dnssec-records]). This is in order to avoid 518 blocking valid signatures from getting through to other 519 security-aware resolvers which are clients of this recursive name 520 server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure 521 recursive server handles queries with the CD bit set. 523 7. Stub Resolver Considerations 525 Although not strictly required to do so by the protocol, most DNS 526 queries originate from stub resolvers. Stub resolvers, by 527 definition, are minimal DNS resolvers which use recursive query mode 528 to offload most of the work of DNS resolution to a recursive name 529 server. Given the widespread use of stub resolvers, the DNSSEC 530 architecture has to take stub resolvers into account, but the 531 security features needed in a stub resolver differ in some respects 532 from those needed in a full security-aware resolver. 534 Even a security-oblivious stub resolver may get some benefit from 535 DNSSEC if the recursive name servers it uses are security-aware, but 536 for the stub resolver to place any real reliance on DNSSEC services, 537 the stub resolver must trust both the recursive name servers in 538 question and the communication channels between itself and those name 539 servers. The first of these issues is a local policy issue: in 540 essence, a security-oblivious stub resolver has no real choice but to 541 place itself at the mercy of the recursive name servers that it uses, 542 since it does not perform DNSSEC validity checks on its own. The 543 second issue requires some kind of channel security mechanism; proper 544 use of DNS transaction authentication mechanisms such as SIG(0) 545 ([RFC2931]) or TSIG ([RFC2845]) would suffice, as would appropriate 546 use of IPsec, and particular implementations may have other choices 547 available, such as operating system specific interprocess 548 communication mechanisms. Confidentiality is not needed for this 549 channel, but data integrity and message authentication are. 551 A security-aware stub resolver that does trust both its recursive 552 name servers and its communication channel to them may choose to 553 examine the setting of the Authenticated Data (AD) bit in the message 554 header of the response messages it receives. The stub resolver can 555 use this flag bit as a hint to find out whether the recursive name 556 server was able to validate signatures for all of the data in the 557 Answer and Authority sections of the response. 559 There is one more step that a security-aware stub resolver can take 560 if, for whatever reason, it is not able to establish a useful trust 561 relationship with the recursive name servers which it uses: it can 562 perform its own signature validation, by setting the Checking 563 Disabled (CD) bit in its query messages. A validating stub resolver 564 is thus able to treat the DNSSEC signatures as a trust relationship 565 between the zone administrator and the stub resolver itself. 567 8. Zone Considerations 569 There are several differences between signed and unsigned zones. A 570 signed zone will contain additional security-related records (RRSIG, 571 DNSKEY, DS and NSEC records). RRSIG and NSEC records may be 572 generated by a signing process prior to serving the zone. The RRSIG 573 records that accompany zone data have defined inception and 574 expiration times, which establish a validity period for the 575 signatures and the zone data the signatures cover. 577 8.1 TTL values vs. RRSIG validity period 579 It is important to note the distinction between a RRset's TTL value 580 and the signature validity period specified by the RRSIG RR covering 581 that RRset. DNSSEC does not change the definition or function of the 582 TTL value, which is intended to maintain database coherency in 583 caches. A caching resolver purges RRsets from its cache no later 584 than the end of the time period specified by the TTL fields of those 585 RRsets, regardless of whether or not the resolver is security-aware. 587 The inception and expiration fields in the RRSIG RR 588 ([I-D.ietf-dnsext-dnssec-records]), on the other hand, specify the 589 time period during which the signature can be used to validate the 590 covered RRset. The signatures associated with signed zone data are 591 only valid for the time period specified by these fields in the RRSIG 592 RRs in question. TTL values cannot extend the validity period of 593 signed RRsets in a resolver's cache, but the resolver may use the 594 time remaining before expiration of the signature validity period of 595 a signed RRset as an upper bound for the TTL of the signed RRset and 596 its associated RRSIG RR in the resolver's cache. 598 8.2 New Temporal Dependency Issues for Zones 600 Information in a signed zone has a temporal dependency which did not 601 exist in the original DNS protocol. A signed zone requires regular 602 maintenance to ensure that each RRset in the zone has a current valid 603 RRSIG RR. The signature validity period of an RRSIG RR is an 604 interval during which the signature for one particular signed RRset 605 can be considered valid, and the signatures of different RRsets in a 606 zone may expire at different times. Re-signing one or more RRsets in 607 a zone will change one or more RRSIG RRs, which in turn will require 608 incrementing the zone's SOA serial number to indicate that a zone 609 change has occurred and re-signing the SOA RRset itself. Thus, 610 re-signing any RRset in a zone may also trigger DNS NOTIFY messages 611 and zone transfers operations. 613 9. Name Server Considerations 615 A security-aware name server should include the appropriate DNSSEC 616 records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from 617 resolvers which have signaled their willingness to receive such 618 records via use of the DO bit in the EDNS header, subject to message 619 size limitations. Since inclusion of these DNSSEC RRs could easily 620 cause UDP message truncation and fallback to TCP, a security-aware 621 name server must also support the EDNS "sender's UDP payload" 622 mechanism. 624 If possible, the private half of each DNSSEC key pair should be kept 625 offline, but this will not be possible for a zone for which DNS 626 dynamic update has been enabled. In the dynamic update case, the 627 primary master server for the zone will have to re-sign the zone when 628 updated, so the private key corresponding to the zone signing key 629 will have to be kept online. This is an example of a situation where 630 the ability to separate the zone's DNSKEY RRset into zone signing 631 key(s) and key signing key(s) may be useful, since the key signing 632 key(s) in such a case can still be kept offline and may have a longer 633 useful lifetime than the zone signing key(s). 635 DNSSEC, by itself, is not enough to protect the integrity of an 636 entire zone during zone transfer operations, since even a signed zone 637 contains some unsigned, nonauthoritative data if the zone has any 638 children. Therefore, zone maintenance operations will require some 639 additional mechanisms (most likely some form of channel security, 640 such as TSIG, SIG(0), or IPsec). 642 10. DNS Security Document Family 644 The DNSSEC document set can be partitioned into several main groups, 645 under the larger umbrella of the DNS base protocol documents. 647 The "DNSSEC protocol document set" refers to the three documents 648 which form the core of the DNS security extensions: 649 1. DNS Security Introduction and Requirements (this document) 650 2. Resource Records for DNS Security Extensions 651 [I-D.ietf-dnsext-dnssec-records] 652 3. Protocol Modifications for the DNS Security Extensions 653 [I-D.ietf-dnsext-dnssec-protocol] 655 Additionally, any document that would add to, or change the core DNS 656 Security extensions would fall into this category. This includes any 657 future work on the communication between security-aware stub 658 resolvers and upstream security-aware recursive name servers. 660 The "Digital Signature Algorithm Specification" document set refers 661 to the group of documents that describe how specific digital 662 signature algorithms should be implemented to fit the DNSSEC resource 663 record format. Each document in this set deals with a specific 664 digital signature algorithm. Please see the appendix on "DNSSEC 665 Algorithm and Digest Types" in [I-D.ietf-dnsext-dnssec-records] for a 666 list of the algorithms that were defined at the time this core 667 specification was written. 669 The "Transaction Authentication Protocol" document set refers to the 670 group of documents that deal with DNS message authentication, 671 including secret key establishment and verification. While not 672 strictly part of the DNSSEC specification as defined in this set of 673 documents, this group is noted because of its relationship to DNSSEC. 675 The final document set, "New Security Uses", refers to documents that 676 seek to use proposed DNS Security extensions for other security 677 related purposes. DNSSEC does not provide any direct security for 678 these new uses, but may be used to support them. Documents that fall 679 in this category include the use of DNS in the storage and 680 distribution of certificates ([RFC2538]). 682 11. IANA Considerations 684 This overview document introduces no new IANA considerations. Please 685 see [I-D.ietf-dnsext-dnssec-records] for a complete review of the 686 IANA considerations introduced by DNSSEC. 688 12. Security Considerations 690 This document introduces the DNS security extensions and describes 691 the document set that contains the new security records and DNS 692 protocol modifications. The extensions provide data origin 693 authentication and data integrity using digital signatures over 694 resource record sets. This section discusses the limitations of 695 these extensions. 697 In order for a security-aware resolver to validate a DNS response, 698 all zones along the path from the trusted starting point to the zone 699 containing the response zones must be signed, and all name servers 700 and resolvers involved in the resolution process must be 701 security-aware, as defined in this document set. A security-aware 702 resolver cannot verify responses originating from an unsigned zone, 703 from a zone not served by a security-aware name server, or for any 704 DNS data which the resolver is only able to obtain through a 705 recursive name server which is not security-aware. If there is a 706 break in the authentication chain such that a security-aware resolver 707 cannot obtain and validate the authentication keys it needs, then the 708 security-aware resolver cannot validate the affected DNS data. 710 This document briefly discusses other methods of adding security to a 711 DNS query, such as using a channel secured by IPsec or using a DNS 712 transaction authentication mechanism such as TSIG ([RFC2845]) or 713 SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC 714 per se. 716 A non-validating security-aware stub resolver, by definition, does 717 not perform DNSSEC signature validation on its own, and thus is 718 vulnerable both to attacks on (and by) the security-aware recursive 719 name servers which perform these checks on its behalf and also to 720 attacks on its communication with those security-aware recursive name 721 servers. Non-validating security-aware stub resolvers should use 722 some form of channel security to defend against the latter threat. 723 The only known defense against the former threat would be for the 724 security-aware stub resolver to perform its own signature validation, 725 at which point, again by definition, it would no longer be a 726 non-validating security-aware stub resolver. 728 DNSSEC does not protect against denial of service attacks. DNSSEC 729 makes DNS vulnerable to a new class of denial of service attacks 730 based on cryptographic operations against security-aware resolvers 731 and security-aware name servers, since an attacker can attempt to use 732 DNSSEC mechanisms to consume a victim's resources. This class of 733 attacks takes at least two forms. An attacker may be able to consume 734 resources in a security-aware resolver's signature validation code by 735 tampering with RRSIG RRs in response messages or by constructing 736 needlessly complex signature chains. An attacker may also be able to 737 consume resources in a security-aware name server which supports DNS 738 dynamic update, by sending a stream of update messages that force the 739 security-aware name server to re-sign some RRsets in the zone more 740 frequently than would otherwise be necessary. 742 DNSSEC does not provide confidentiality, due to a deliberate design 743 choice. 745 DNSSEC introduces the ability for a hostile party to enumerate all 746 the names in a zone by following the NSEC chain. NSEC RRs assert 747 which names do not exist in a zone by linking from existing name to 748 existing name along a canonical ordering of all the names within a 749 zone. Thus, an attacker can query these NSEC RRs in sequence to 750 obtain all the names in a zone. While not an attack on the DNS 751 itself, this could allow an attacker to map network hosts or other 752 resources by enumerating the contents of a zone. 754 DNSSEC introduces significant additional complexity to the DNS, and 755 thus introduces many new opportunities for implementation bugs and 756 misconfigured zones. In particular, enabling DNSSEC signature 757 validation in a resolver may cause entire legitimate zones to become 758 effectively unreachable due to DNSSEC configuration errors or bugs. 760 DNSSEC does not protect against tampering with unsigned zone data. 761 Non-authoritative data at zone cuts (glue and NS RRs in the parent 762 zone) are not signed. This does not pose a problem when validating 763 the authentication chain, but does mean that the non-authoritative 764 data itself is vulnerable to tampering during zone transfer 765 operations. Thus, while DNSSEC can provide data origin 766 authentication and data integrity for RRsets, it cannot do so for 767 zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be 768 used to protect zone transfer operations. 770 Please see [I-D.ietf-dnsext-dnssec-records] and 771 [I-D.ietf-dnsext-dnssec-protocol] for additional security 772 considerations. 774 13. Acknowledgements 776 This document was created from the input and ideas of the members of 777 the DNS Extensions Working Group. While explicitly listing everyone 778 who has contributed during the decade during which DNSSEC has been 779 under development would be an impossible task, the editors would 780 particularly like to thank the following people for their 781 contributions to and comments on this document set: Jaap Akkerhuis, 782 Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, 783 David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald 784 Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, 785 Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip 786 Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, 787 Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon 788 Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, 789 Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, 790 Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ 791 Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob 792 Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, 793 Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, 794 Brian Wellington, and Suzanne Woolf. 796 No doubt the above list is incomplete. We apologize to anyone we 797 left out. 799 14. References 801 14.1 Normative References 803 [I-D.ietf-dnsext-dnssec-protocol] 804 Arends, R., Austein, R., Larson, M., Massey, D. and S. 805 Rose, "Protocol Modifications for the DNS Security 806 Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in 807 progress), May 2004. 809 [I-D.ietf-dnsext-dnssec-records] 810 Arends, R., Austein, R., Larson, M., Massey, D. and S. 811 Rose, "Resource Records for DNS Security Extensions", 812 draft-ietf-dnsext-dnssec-records-08 (work in progress), 813 May 2004. 815 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 816 STD 13, RFC 1034, November 1987. 818 [RFC1035] Mockapetris, P., "Domain names - implementation and 819 specification", STD 13, RFC 1035, November 1987. 821 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 822 RFC 2535, March 1999. 824 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 825 2671, August 1999. 827 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 828 3225, December 2001. 830 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 831 message size requirements", RFC 3226, December 2001. 833 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 834 Resource Record (RR)", RFC 3445, December 2002. 836 14.2 Informative References 838 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 839 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 840 April 1997. 842 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 843 Specification", RFC 2181, July 1997. 845 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 846 NCACHE)", RFC 2308, March 1998. 848 [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in 849 the Domain Name System (DNS)", RFC 2538, March 1999. 851 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 852 Wellington, "Secret Key Transaction Authentication for DNS 853 (TSIG)", RFC 2845, May 2000. 855 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 856 SIG(0)s)", RFC 2931, September 2000. 858 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 859 Update", RFC 3007, November 2000. 861 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) 862 Signing Authority", RFC 3008, November 2000. 864 [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone 865 Status", RFC 3090, March 2001. 867 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 868 (RR) Types", RFC 3597, September 2003. 870 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 871 Authenticated Data (AD) bit", RFC 3655, November 2003. 873 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 874 (RR)", RFC 3658, December 2003. 876 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 877 Signer", RFC 3755, April 2004. 879 [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure 880 Entry Point Flag", RFC 3757, April 2004. 882 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 883 Name System (DNS)", RFC 3833, August 2004. 885 [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) 886 RDATA Format", RFC 3845, August 2004. 888 Authors' Addresses 890 Roy Arends 891 Telematica Instituut 892 Drienerlolaan 5 893 7522 NB Enschede 894 NL 896 EMail: roy.arends@telin.nl 898 Rob Austein 899 Internet Systems Consortium 900 950 Charter Street 901 Redwood City, CA 94063 902 USA 904 EMail: sra@isc.org 906 Matt Larson 907 VeriSign, Inc. 908 21345 Ridgetop Circle 909 Dulles, VA 20166-6503 910 USA 912 EMail: mlarson@verisign.com 914 Dan Massey 915 USC Information Sciences Institute 916 3811 N. Fairfax Drive 917 Arlington, VA 22203 918 USA 920 EMail: masseyd@isi.edu 922 Scott Rose 923 National Institute for Standards and Technology 924 100 Bureau Drive 925 Gaithersburg, MD 20899-8920 926 USA 928 EMail: scott.rose@nist.gov 930 Intellectual Property Statement 932 The IETF takes no position regarding the validity or scope of any 933 Intellectual Property Rights or other rights that might be claimed to 934 pertain to the implementation or use of the technology described in 935 this document or the extent to which any license under such rights 936 might or might not be available; nor does it represent that it has 937 made any independent effort to identify any such rights. Information 938 on the procedures with respect to rights in RFC documents can be 939 found in BCP 78 and BCP 79. 941 Copies of IPR disclosures made to the IETF Secretariat and any 942 assurances of licenses to be made available, or the result of an 943 attempt made to obtain a general license or permission for the use of 944 such proprietary rights by implementers or users of this 945 specification can be obtained from the IETF on-line IPR repository at 946 http://www.ietf.org/ipr. 948 The IETF invites any interested party to bring to its attention any 949 copyrights, patents or patent applications, or other proprietary 950 rights that may cover technology that may be required to implement 951 this standard. Please address the information to the IETF at 952 ietf-ipr@ietf.org. 954 Disclaimer of Validity 956 This document and the information contained herein are provided on an 957 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 958 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 959 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 960 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 961 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 962 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 964 Copyright Statement 966 Copyright (C) The Internet Society (2004). This document is subject 967 to the rights, licenses and restrictions contained in BCP 78, and 968 except as set forth therein, the authors retain all their rights. 970 Acknowledgment 972 Funding for the RFC Editor function is currently provided by the 973 Internet Society.