idnits 2.17.00 (12 Aug 2021) /tmp/idnits17628/draft-ietf-dnsext-dnssec-intro-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 357 has weird spacing: '...t. See for f...' -- 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 6577 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: draft-ietf-dnsext-dnssec-protocol has been published as RFC 4035 == Outdated reference: draft-ietf-dnsext-dnssec-records has been published as RFC 4034 ** 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) == Outdated reference: draft-ietf-dnsext-dns-threats has been published as RFC 3833 == Outdated reference: draft-ietf-dnsext-nsec-rdata has been published as RFC 3845 -- 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) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 10 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 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 May 17, 2004 14 DNS Security Introduction and Requirements 15 draft-ietf-dnsext-dnssec-intro-10 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 The Domain Name System Security Extensions (DNSSEC) add data origin 46 authentication and data integrity to the Domain Name System. This 47 document introduces these extensions, and describes their 48 capabilities and limitations. This document also discusses the 49 services that the DNS security extensions do and do not provide. 51 Last, this document describes the interrelationships between the 52 group of documents that collectively describe DNSSEC. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 58 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 59 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 60 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 61 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 62 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 63 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 64 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 65 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 66 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 67 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 68 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 69 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 71 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 72 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 73 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 74 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 75 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 77 Intellectual Property and Copyright Statements . . . . . . . . 26 79 1. Introduction 81 This document introduces the Domain Name System Security Extensions 82 (DNSSEC). This document and its two companion documents 83 ([I-D.ietf-dnsext-dnssec-records] and 84 [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the 85 security extensions defined in RFC 2535 [RFC2535] and its 86 predecessors. These security extensions consist of a set of new 87 resource record types and modifications to the existing DNS protocol 88 [RFC1035]. The new records and protocol modifications are not fully 89 described in this document, but are described in a family of 90 documents outlined in Section 10. Section 3 and Section 4 describe 91 the capabilities and limitations of the security extensions in 92 greater detail. Section 5 discusses the scope of the document set. 93 Section 6, Section 7, Section 8, and Section 9 discuss the effect 94 that these security extensions will have on resolvers, stub 95 resolvers, zones and name servers. 97 This document and its two companions update and obsolete RFCs 2535 98 [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 99 [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress 100 [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but 101 does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 102 [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts 103 of 3226 [RFC3226] (dealing with DNSSEC). 105 The DNS security extensions provide origin authentication and 106 integrity protection for DNS data, as well as a means of public key 107 distribution. These extensions do not provide confidentiality. 109 2. Definitions of Important DNSSEC Terms 111 This section defines a number of terms used in this document set. 112 Since this is intended to be useful as a reference while reading the 113 rest of the document set, first-time readers may wish to skim this 114 section quickly, read the rest of this document, then come back to 115 this section. 117 Authentication Chain: An alternating sequence of DNSKEY RRsets and DS 118 RRsets forms a chain of signed data, with each link in the chain 119 vouching for the next. A DNSKEY RR is used to verify the 120 signature covering a DS RR and allows the DS RR to be 121 authenticated. The DS RR contains a hash of another DNSKEY RR and 122 this new DNSKEY RR is authenticated by matching the hash in the DS 123 RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset 124 and, in turn, some DNSKEY RR in this set may be used to 125 authenticate another DS RR and so forth until the chain finally 126 ends with a DNSKEY RR whose corresponding private key signs the 127 desired DNS data. For example, the root DNSKEY RRset can be used 128 to authenticate the DS RRset for "example." The "example." DS 129 RRset contains a hash that matches some "example." DNSKEY, and 130 this DNSKEY's corresponding private key signs the "example." 131 DNSKEY RRset. Private key counterparts of the "example." DNSKEY 132 RRset sign data records such as "www.example." as well as DS RRs 133 for delegations such as "subzone.example." 135 Authentication Key: A public key that a security-aware resolver has 136 verified and can therefore use to authenticate data. A 137 security-aware resolver can obtain authentication keys in three 138 ways. First, the resolver is generally configured to know about 139 at least one public key; this configured data is usually either 140 the public key itself or a hash of the public key as found in the 141 DS RR (see "trust anchor"). Second, the resolver may use an 142 authenticated public key to verify a DS RR and its associated 143 DNSKEY RR. Third, the resolver may be able to determine that a 144 new public key has been signed by the private key corresponding to 145 another public key which the resolver has verified. Note that the 146 resolver must always be guided by local policy when deciding 147 whether to authenticate a new public key, even if the local policy 148 is simply to authenticate any new public key for which the 149 resolver is able verify the signature. 151 Delegation Point: Term used to describe the name at the parental side 152 of a zone cut. That is, the delegation point for "foo.example" 153 would be the foo.example node in the "example" zone (as opposed to 154 the zone apex of the "foo.example" zone). 156 Island of Security: Term used to describe a signed, delegated zone 157 that does not have an authentication chain from its delegating 158 parent. That is, there is no DS RR containing a hash of a DNSKEY 159 RR for the island in its delegating parent zone (see 160 [I-D.ietf-dnsext-dnssec-records]). An island of security is served 161 by security-aware name servers and may provide authentication 162 chains to any delegated child zones. Responses from an island of 163 security or its descendents can only be authenticated if its 164 authentication keys can be authenticated by some trusted means out 165 of band from the DNS protocol. 167 Key Signing Key: An authentication key that corresponds to a private 168 key used to sign one or more other authentication keys for a given 169 zone. Typically, the private key corresponding to a key signing 170 key will sign a zone signing key, which in turn has a 171 corresponding private key which will sign other zone data. Local 172 policy may require the zone signing key to be changed frequently, 173 while the key signing key may have a longer validity period in 174 order to provide a more stable secure entry point into the zone. 175 Designating an authentication key as a key signing key is purely 176 an operational issue: DNSSEC validation does not distinguish 177 between key signing keys and other DNSSEC authentication keys, and 178 it is possible to use a single key as both a key signing key and a 179 zone signing key. Key signing keys are discussed in more detail 180 in [RFC3757]. Also see: zone signing key. 182 Non-Validating Security-Aware Stub Resolver: A security-aware stub 183 resolver which trusts one or more security-aware recursive name 184 servers to perform most of the tasks discussed in this document 185 set on its behalf. In particular, a non-validating security-aware 186 stub resolver is an entity which sends DNS queries, receives DNS 187 responses, and is capable of establishing an appropriately secured 188 channel to a security-aware recursive name server which will 189 provide these services on behalf of the security-aware stub 190 resolver. See also: security-aware stub resolver, validating 191 security-aware stub resolver. 193 Non-Validating Stub Resolver: A less tedious term for a 194 non-validating security-aware stub resolver. 196 Security-Aware Name Server: An entity acting in the role of a name 197 server (defined in section 2.4 of [RFC1034]) that understands the 198 DNS security extensions defined in this document set. In 199 particular, a security-aware name server is an entity which 200 receives DNS queries, sends DNS responses, supports the EDNS0 201 [RFC2671] message size extension and the DO bit [RFC3225], and 202 supports the RR types and message header bits defined in this 203 document set. 205 Security-Aware Recursive Name Server: An entity which acts in both 206 the security-aware name server and security-aware resolver roles. 207 A more cumbersome equivalent phrase would be "a security-aware 208 name server which offers recursive service". 210 Security-Aware Resolver: An entity acting in the role of a resolver 211 (defined in section 2.4 of [RFC1034]) which understands the DNS 212 security extensions defined in this document set. In particular, 213 a security-aware resolver is an entity which sends DNS queries, 214 receives DNS responses, supports the EDNS0 [RFC2671] message size 215 extension and the DO bit [RFC3225], and is capable of using the RR 216 types and message header bits defined in this document set to 217 provide DNSSEC services. 219 Security-Aware Stub Resolver: An entity acting in the role of a stub 220 resolver (defined in section 5.3.1 of [RFC1034]) which has enough 221 of an understanding the DNS security extensions defined in this 222 document set to provide additional services not available from a 223 security-oblivious stub resolver. Security-aware stub resolvers 224 may be either "validating" or "non-validating" depending on 225 whether the stub resolver attempts to verify DNSSEC signatures on 226 its own or trusts a friendly security-aware name server to do so. 227 See also: validating stub resolver, non-validating stub resolver. 229 Security-Oblivious : An that is not 230 "security-aware". 232 Signed Zone: A zone whose RRsets are signed and which contains 233 properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS 234 records. 236 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A 237 validating security-aware resolver uses this public key or hash as 238 a starting point for building the authentication chain to a signed 239 DNS response. In general, a validating resolver will need to 240 obtain the initial values of its trust anchors via some secure or 241 trusted means outside the DNS protocol. Presence of a trust 242 anchor also implies that the resolver should expect the zone to 243 which the trust anchor points to be signed 245 Unsigned Zone: A zone that is not signed. 247 Validating Security-Aware Stub Resolver: A security-aware resolver 248 that sends queries in recursive mode but which performs signature 249 validation on its own rather than just blindly trusting an 250 upstream security-aware recursive name server. See also: 251 security-aware stub resolver, non-validating security-aware stub 252 resolver. 254 Validating Stub Resolver: A less tedious term for a validating 255 security-aware stub resolver. 257 Zone Signing Key: An authentication key that corresponds to a private 258 key used to sign a zone. Typically a zone signing key will be 259 part of the same DNSKEY RRset as the key signing key whose 260 corresponding private key signs this DNSKEY RRset, but the zone 261 signing key is used for a slightly different purpose, and may 262 differ from the key signing key in other ways, such as validity 263 lifetime. Designating an authentication key as a zone signing key 264 is purely an operational issue: DNSSEC validation does not 265 distinguish between zone signing keys and other DNSSEC 266 authentication keys, and it is possible to use a single key as 267 both a key signing key and a zone signing key. See also: key 268 signing key. 270 3. Services Provided by DNS Security 272 The Domain Name System (DNS) security extensions provide origin 273 authentication and integrity assurance services for DNS data, 274 including mechanisms for authenticated denial of existence of DNS 275 data. These mechanisms are described below. 277 These mechanisms require changes to the DNS protocol. DNSSEC adds 278 four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two 279 new message header bits (CD and AD). In order to support the larger 280 DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also 281 requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support 282 for the DO bit [RFC3225], so that a security-aware resolver can 283 indicate in its queries that it wishes to receive DNSSEC RRs in 284 response messages. 286 These services protect against most of the threats to the Domain Name 287 System described in [I-D.ietf-dnsext-dns-threats]. 289 3.1 Data Origin Authentication and Data Integrity 291 DNSSEC provides authentication by associating cryptographically 292 generated digital signatures with DNS RRsets. These digital 293 signatures are stored in a new resource record, the RRSIG record. 294 Typically, there will be a single private key that signs a zone's 295 data, but multiple keys are possible: for example, there may be keys 296 for each of several different digital signature algorithms. If a 297 security-aware resolver reliably learns a zone's public key, it can 298 authenticate that zone's signed data. An important DNSSEC concept is 299 that the key that signs a zone's data is associated with the zone 300 itself and not with the zone's authoritative name servers (public 301 keys for DNS transaction authentication mechanisms may also appear in 302 zones, as described in [RFC2931], but DNSSEC itself is concerned with 303 object security of DNS data, not channel security of DNS 304 transactions). 306 A security-aware resolver can learn a zone's public key either by 307 having a trust anchor configured into the resolver or by normal DNS 308 resolution. To allow the latter, public keys are stored in a new 309 type of resource record, the DNSKEY RR. Note that the private keys 310 used to sign zone data must be kept secure, and should be stored 311 offline when practical to do so. To discover a public key reliably 312 via DNS resolution, the target key itself needs to be signed by 313 either a configured authentication key or another key that has been 314 authenticated previously. Security-aware resolvers authenticate zone 315 information by forming an authentication chain from a newly learned 316 public key back to a previously known authentication public key, 317 which in turn either has been configured into the resolver or must 318 have been learned and verified previously. Therefore, the resolver 319 must be configured with at least one trust anchor. If the configured 320 key is a zone signing key, then it will authenticate the associated 321 zone; if the configured key is a key signing key, it will 322 authenticate a zone signing key. If the resolver has been configured 323 with the hash of a key rather than the key itself, the resolver may 324 need to obtain the key via a DNS query. To help security-aware 325 resolvers establish this authentication chain, security-aware name 326 servers attempt to send the signature(s) needed to authenticate a 327 zone's public key(s) in the DNS reply message along with the public 328 key itself, provided there is space available in the message. 330 The Delegation Signer (DS) RR type simplifies some of the 331 administrative tasks involved in signing delegations across 332 organizational boundaries. The DS RRset resides at a delegation 333 point in a parent zone and indicates the public key(s) corresponding 334 to the private key(s) used to self-sign the DNSKEY RRset at the 335 delegated child zone's apex. The administrator of the child zone, in 336 turn, uses the private key(s) corresponding to one or more of the 337 public keys in this DNSKEY RRset to sign the child zone's data. The 338 typical authentication chain is therefore 339 DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more 340 DS->DNSKEY subchains. DNSSEC permits more complex authentication 341 chains, such as additional layers of DNSKEY RRs signing other DNSKEY 342 RRs within a zone. 344 A security-aware resolver normally constructs this authentication 345 chain from the root of the DNS hierarchy down to the leaf zones based 346 on configured knowledge of the public key for the root. Local 347 policy, however, may also allow a security-aware resolver to use one 348 or more configured public keys (or hashes of public keys) other than 349 the root public key, or may not provide configured knowledge of the 350 root public key, or may prevent the resolver from using particular 351 public keys for arbitrary reasons even if those public keys are 352 properly signed with verifiable signatures. DNSSEC provides 353 mechanisms by which a security-aware resolver can determine whether 354 an RRset's signature is "valid" within the meaning of DNSSEC. In the 355 final analysis however, authenticating both DNS keys and data is a 356 matter of local policy, which may extend or even override the 357 protocol extensions defined in this document set. See for further 358 discussion. 360 3.2 Authenticating Name and Type Non-Existence 362 The security mechanism described in Section 3.1 only provides a way 363 to sign existing RRsets in a zone. The problem of providing negative 364 responses with the same level of authentication and integrity 365 requires the use of another new resource record type, the NSEC 366 record. The NSEC record allows a security-aware resolver to 367 authenticate a negative reply for either name or type non-existence 368 via the same mechanisms used to authenticate other DNS replies. Use 369 of NSEC records requires a canonical representation and ordering for 370 domain names in zones. Chains of NSEC records explicitly describe 371 the gaps, or "empty space", between domain names in a zone, as well 372 as listing the types of RRsets present at existing names. Each NSEC 373 record is signed and authenticated using the mechanisms described in 374 Section 3.1. 376 4. Services Not Provided by DNS Security 378 DNS was originally designed with the assumptions that the DNS will 379 return the same answer to any given query regardless of who may have 380 issued the query, and that all data in the DNS is thus visible. 381 Accordingly, DNSSEC is not designed to provide confidentiality, 382 access control lists, or other means of differentiating between 383 inquirers. 385 DNSSEC provides no protection against denial of service attacks. 386 Security-aware resolvers and security-aware name servers are 387 vulnerable to an additional class of denial of service attacks based 388 on cryptographic operations. Please see Section 12 for details. 390 The DNS security extensions provide data and origin authentication 391 for DNS data. The mechanisms outlined above are not designed to 392 protect operations such as zone transfers and dynamic update 393 [RFC3007]. Message authentication schemes described in [RFC2845] and 394 [RFC2931] address security operations that pertain to these 395 transactions. 397 5. Scope of the DNSSEC Document Set and Last Hop Issues 399 The specification in this document set defines the behavior for zone 400 signers and security-aware name servers and resolvers in such a way 401 that the validating entities can unambiguously determine the state of 402 the data. 404 A validating resolver can determine these 4 states: 406 Secure: The validating resolver has a trust anchor, a chain of trust 407 and is able to verify all the signatures in the response. 409 Insecure: The validating resolver has a trust anchor, a chain of 410 trust, and, at some delegation point, signed proof of the 411 non-existence of a DS record. That indicates that subsequent 412 branches in the tree are provably insecure. A validating resolver 413 may have local policy to mark parts of the domain space as 414 insecure. 416 Bogus: The validating resolver has a trust anchor and there is a 417 secure delegation which is indicating that subsidiary data will be 418 signed, but the response fails to validate due to one or more 419 reasons: missing signatures, expired signatures, signatures with 420 unsupported algorithms, data missing which the relevant NSEC RR 421 says should be present, and so forth. 423 Indeterminate: There is no trust anchor which would indicate that a 424 specific portion of the tree is secure. This is the default 425 operation mode. 427 This specification only defines how security aware name servers can 428 signal non-validating stub resolvers that data was found to be bogus 429 (using RCODE=2, "Server Failure" -- see 430 [I-D.ietf-dnsext-dnssec-protocol]). 432 There is a mechanism for security aware name servers to signal 433 security-aware stub resolvers that data was found to be secure (using 434 the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). 436 This specification does not define a format for communicating why 437 responses were found to be bogus or marked as insecure. The current 438 signaling mechanism does not distinguish between indeterminate and 439 insecure. 441 A method for signaling advanced error codes and policy between a 442 security aware stub resolver and security aware recursive nameservers 443 is a topic for future work, as is the interface between a security 444 aware resolver and the applications that use it. Note, however, that 445 the lack of the specification of such communication does not prohibit 446 deployment of signed zones or the deployment of security aware 447 recursive name servers that prohibit propagation of bogus data to the 448 applications. 450 6. Resolver Considerations 452 A security-aware resolver needs to be able to perform cryptographic 453 functions necessary to verify digital signatures using at least the 454 mandatory-to-implement algorithm(s). Security-aware resolvers must 455 also be capable of forming an authentication chain from a newly 456 learned zone back to an authentication key, as described above. This 457 process might require additional queries to intermediate DNS zones to 458 obtain necessary DNSKEY, DS and RRSIG records. A security-aware 459 resolver should be configured with at least one trust anchor as the 460 starting point from which it will attempt to establish authentication 461 chains. 463 If a security-aware resolver is separated from the relevant 464 authoritative name servers by a recursive name server or by any sort 465 of device which acts as a proxy for DNS, and if the recursive name 466 server or proxy is not security-aware, the security-aware resolver 467 may not be capable of operating in a secure mode. For example, if a 468 security-aware resolver's packets are routed through a network 469 address translation device that includes a DNS proxy which is not 470 security-aware, the security-aware resolver may find it difficult or 471 impossible to obtain or validate signed DNS data. 473 If a security-aware resolver must rely on an unsigned zone or a name 474 server that is not security aware, the resolver may not be able to 475 validate DNS responses, and will need a local policy on whether to 476 accept unverified responses. 478 A security-aware resolver should take a signature's validation period 479 into consideration when determining the TTL of data in its cache, to 480 avoid caching signed data beyond the validity period of the 481 signature, but should also allow for the possibility that the 482 security-aware resolver's own clock is wrong. Thus, a security-aware 483 resolver which is part of a security-aware recursive name server will 484 need to pay careful attention to the DNSSEC "checking disabled" (CD) 485 bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid 486 blocking valid signatures from getting through to other 487 security-aware resolvers which are clients of this recursive name 488 server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure 489 recursive server handles queries with the CD bit set. 491 7. Stub Resolver Considerations 493 Although not strictly required to do so by the protocol, most DNS 494 queries originate from stub resolvers. Stub resolvers, by 495 definition, are minimal DNS resolvers which use recursive query mode 496 to offload most of the work of DNS resolution to a recursive name 497 server. Given the widespread use of stub resolvers, the DNSSEC 498 architecture has to take stub resolvers into account, but the 499 security features needed in a stub resolver differ in some respects 500 from those needed in a full security-aware resolver. 502 Even a security-oblivious stub resolver may get some benefit from 503 DNSSEC if the recursive name servers it uses are security-aware, but 504 for the stub resolver to place any real reliance on DNSSEC services, 505 the stub resolver must trust both the recursive name servers in 506 question and the communication channels between itself and those name 507 servers. The first of these issues is a local policy issue: in 508 essence, a security-oblivious stub resolver has no real choice but to 509 place itself at the mercy of the recursive name servers that it uses, 510 since it does not perform DNSSEC validity checks on its own. The 511 second issue requires some kind of channel security mechanism; proper 512 use of DNS transaction authentication mechanisms such as SIG(0) or 513 TSIG would suffice, as would appropriate use of IPsec, and particular 514 implementations may have other choices available, such as operating 515 system specific interprocess communication mechanisms. 516 Confidentiality is not needed for this channel, but data integrity 517 and message authentication are. 519 A security-aware stub resolver that does trust both its recursive 520 name servers and its communication channel to them may choose to 521 examine the setting of the AD bit in the message header of the 522 response messages it receives. The stub resolver can use this flag 523 bit as a hint to find out whether the recursive name server was able 524 to validate signatures for all of the data in the Answer and 525 Authority sections of the response. 527 There is one more step that a security-aware stub resolver can take 528 if, for whatever reason, it is not able to establish a useful trust 529 relationship with the recursive name servers which it uses: it can 530 perform its own signature validation, by setting the Checking 531 Disabled (CD) bit in its query messages. A validating stub resolver 532 is thus able to treat the DNSSEC signatures as a trust relationship 533 between the zone administrator and the stub resolver itself. 535 8. Zone Considerations 537 There are several differences between signed and unsigned zones. A 538 signed zone will contain additional security-related records (RRSIG, 539 DNSKEY, DS and NSEC records). RRSIG and NSEC records may be 540 generated by a signing process prior to serving the zone. The RRSIG 541 records that accompany zone data have defined inception and 542 expiration times, which establish a validity period for the 543 signatures and the zone data the signatures cover. 545 8.1 TTL values vs. RRSIG validity period 547 It is important to note the distinction between a RRset's TTL value 548 and the signature validity period specified by the RRSIG RR covering 549 that RRset. DNSSEC does not change the definition or function of the 550 TTL value, which is intended to maintain database coherency in 551 caches. A caching resolver purges RRsets from its cache no later than 552 the end of the time period specified by the TTL fields of those 553 RRsets, regardless of whether or not the resolver is security-aware. 555 The inception and expiration fields in the RRSIG RR 556 [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time 557 period during which the signature can be used to validate the covered 558 RRset. The signatures associated with signed zone data are only 559 valid for the time period specified by these fields in the RRSIG RRs 560 in question. TTL values cannot extend the validity period of signed 561 RRsets in a resolver's cache, but the resolver may use the time 562 remaining before expiration of the signature validity period of a 563 signed RRset as an upper bound for the TTL of the signed RRset and 564 its associated RRSIG RR in the resolver's cache. 566 8.2 New Temporal Dependency Issues for Zones 568 Information in a signed zone has a temporal dependency which did not 569 exist in the original DNS protocol. A signed zone requires regular 570 maintenance to ensure that each RRset in the zone has a current valid 571 RRSIG RR. The signature validity period of an RRSIG RR is an 572 interval during which the signature for one particular signed RRset 573 can be considered valid, and the signatures of different RRsets in a 574 zone may expire at different times. Re-signing one or more RRsets in 575 a zone will change one or more RRSIG RRs, which in turn will require 576 incrementing the zone's SOA serial number to indicate that a zone 577 change has occurred and re-signing the SOA RRset itself. Thus, 578 re-signing any RRset in a zone may also trigger DNS NOTIFY messages 579 and zone transfers operations. 581 9. Name Server Considerations 583 A security-aware name server should include the appropriate DNSSEC 584 records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from 585 resolvers which have signaled their willingness to receive such 586 records via use of the DO bit in the EDNS header, subject to message 587 size limitations. Since inclusion of these DNSSEC RRs could easily 588 cause UDP message truncation and fallback to TCP, a security-aware 589 name server must also support the EDNS "sender's UDP payload" 590 mechanism. 592 If possible, the private half of each DNSSEC key pair should be kept 593 offline, but this will not be possible for a zone for which DNS 594 dynamic update has been enabled. In the dynamic update case, the 595 primary master server for the zone will have to re-sign the zone when 596 updated, so the private key corresponding to the zone signing key 597 will have to be kept online. This is an example of a situation where 598 the ability to separate the zone's DNSKEY RRset into zone signing 599 key(s) and key signing key(s) may be useful, since the key signing 600 key(s) in such a case can still be kept offline and may have a longer 601 useful lifetime than the zone signing key(s). 603 DNSSEC, by itself, is not enough to protect the integrity of an 604 entire zone during zone transfer operations, since even a signed zone 605 contains some unsigned, nonauthoritative data if the zone has any 606 children. Therefore, zone maintenance operations will require some 607 additional mechanisms (most likely some form of channel security, 608 such as TSIG, SIG(0), or IPsec). 610 10. DNS Security Document Family 612 The DNSSEC document set can be partitioned into several main groups, 613 under the larger umbrella of the DNS base protocol documents. 615 The "DNSSEC protocol document set" refers to the three documents 616 which form the core of the DNS security extensions: 617 1. DNS Security Introduction and Requirements (this document) 618 2. Resource Records for DNS Security Extensions 619 [I-D.ietf-dnsext-dnssec-records] 620 3. Protocol Modifications for the DNS Security Extensions 621 [I-D.ietf-dnsext-dnssec-protocol] 623 Additionally, any document that would add to, or change the core DNS 624 Security extensions would fall into this category. This includes any 625 future work on the communication between security-aware stub 626 resolvers and upstream security-aware recursive name servers. 628 The "Digital Signature Algorithm Specification" document set refers 629 to the group of documents that describe how specific digital 630 signature algorithms should be implemented to fit the DNSSEC resource 631 record format. Each document in this set deals with a specific 632 digital signature algorithm. 634 The "Transaction Authentication Protocol" document set refers to the 635 group of documents that deal with DNS message authentication, 636 including secret key establishment and verification. While not 637 strictly part of the DNSSEC specification as defined in this set of 638 documents, this group is noted because of its relationship to DNSSEC. 640 The final document set, "New Security Uses", refers to documents that 641 seek to use proposed DNS Security extensions for other security 642 related purposes. DNSSEC does not provide any direct security for 643 these new uses, but may be used to support them. Documents that fall 644 in this category include the use of DNS in the storage and 645 distribution of certificates [RFC2538]. 647 11. IANA Considerations 649 This overview document introduces no new IANA considerations. Please 650 see [I-D.ietf-dnsext-dnssec-records] for a complete review of the 651 IANA considerations introduced by DNSSEC. 653 12. Security Considerations 655 This document introduces the DNS security extensions and describes 656 the document set that contains the new security records and DNS 657 protocol modifications. The extensions provide data origin 658 authentication and data integrity using digital signatures over 659 resource record sets.This document discusses the capabilities and 660 limitations of these extensions. 662 In order for a security-aware resolver to validate a DNS response, 663 all zones along the path from the trusted starting point to the zone 664 containing the response zones must be signed, and all name servers 665 and resolvers involved in the resolution process must be 666 security-aware, as defined in this document set. A security-aware 667 resolver cannot verify responses originating from an unsigned zone, 668 from a zone not served by a security-aware name server, or for any 669 DNS data which the resolver is only able to obtain through a 670 recursive name server which is not security-aware. If there is a 671 break in the authentication chain such that a security-aware resolver 672 cannot obtain and validate the authentication keys it needs, then the 673 security-aware resolver cannot validate the affected DNS data. 675 This document briefly discusses other methods of adding security to a 676 DNS query, such as using a channel secured by IPsec or using a DNS 677 transaction authentication mechanism, but transaction security is not 678 part of DNSSEC per se. 680 A non-validating security-aware stub resolver, by definition, does 681 not perform DNSSEC signature validation on its own, and thus is 682 vulnerable both to attacks on (and by) the security-aware recursive 683 name servers which perform these checks on its behalf and also to 684 attacks on its communication with those security-aware recursive name 685 servers. Non-validating security-aware stub resolvers should use some 686 form of channel security to defend against the latter threat. The 687 only known defense against the former threat would be for the 688 security-aware stub resolver to perform its own signature validation, 689 at which point, again by definition, it would no longer be a 690 non-validating security-aware stub resolver. 692 DNSSEC does not protect against denial of service attacks. DNSSEC 693 makes DNS vulnerable to a new class of denial of service attacks 694 based on cryptographic operations against security-aware resolvers 695 and security-aware name servers, since an attacker can attempt to use 696 DNSSEC mechanisms to consume a victim's resources. This class of 697 attacks takes at least two forms. An attacker may be able to consume 698 resources in a security-aware resolver's signature validation code by 699 tampering with RRSIG RRs in response messages or by constructing 700 needlessly complex signature chains. An attacker may also be able to 701 consume resources in a security-aware name server which supports DNS 702 dynamic update, by sending a stream of update messages that force the 703 security-aware name server to re-sign some RRsets in the zone more 704 frequently than would otherwise be necessary. 706 DNSSEC introduces the ability for a hostile party to enumerate all 707 the names in a zone by following the NSEC chain. NSEC RRs assert 708 which names do not exist in a zone by linking from existing name to 709 existing name along a canonical ordering of all the names within a 710 zone. Thus, an attacker can query these NSEC RRs in sequence to 711 obtain all the names in a zone. While not an attack on the DNS 712 itself, this could allow an attacker to map network hosts or other 713 resources by enumerating the contents of a zone. There are non-DNS 714 protocol means of detecting and limiting this attack beyond the scope 715 of this document set. 717 DNSSEC introduces significant additional complexity to the DNS, and 718 thus introduces many new opportunities for implementation bugs and 719 misconfigured zones. In particular, enabling DNSSEC signature 720 validation in a resolver may cause entire legitimate zones to become 721 effectively unreachable due to DNSSEC configuration errors or bugs. 723 DNSSEC does not provide confidentiality, due to a deliberate design 724 choice. 726 DNSSEC does not protect against tampering with unsigned zone data. 727 Non-authoritative data at zone cuts (glue and NS RRs in the parent 728 zone) are not signed. This does not pose a problem when validating 729 the authentication chain, but does mean that the non-authoritative 730 data itself is vulnerable to tampering during zone transfer 731 operations. Thus, while DNSSEC can provide data origin 732 authentication and data integrity for RRsets, it cannot do so for 733 zones, and other mechanisms must be used to protect zone transfer 734 operations. 736 Please see [I-D.ietf-dnsext-dnssec-records] and 737 [I-D.ietf-dnsext-dnssec-protocol] for additional security 738 considerations. 740 13. Acknowledgements 742 This document was created from the input and ideas of the members of 743 the DNS Extensions Working Group. While explicitly listing everyone 744 who has contributed during the decade during which DNSSEC has been 745 under development would be an impossible task, the editors would 746 particularly like to thank the following people for their 747 contributions to and comments on this document set: Mark Andrews, 748 Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, 749 Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael 750 Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip 751 Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf 752 Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted 753 Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson, 754 Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik 755 Rozendaal, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, and 756 Brian Wellington. 758 No doubt the above list is incomplete. We apologize to anyone we 759 left out. 761 14. References 763 14.1 Normative References 765 [I-D.ietf-dnsext-dnssec-protocol] 766 Arends, R., Austein, R., Larson, M., Massey, D. and S. 767 Rose, "Protocol Modifications for the DNS Security 768 Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in 769 progress), May 2004. 771 [I-D.ietf-dnsext-dnssec-records] 772 Arends, R., Austein, R., Larson, M., Massey, D. and S. 773 Rose, "Resource Records for DNS Security Extensions", 774 draft-ietf-dnsext-dnssec-records-08 (work in progress), 775 May 2004. 777 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 778 STD 13, RFC 1034, November 1987. 780 [RFC1035] Mockapetris, P., "Domain names - implementation and 781 specification", STD 13, RFC 1035, November 1987. 783 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 784 RFC 2535, March 1999. 786 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 787 2671, August 1999. 789 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 790 3225, December 2001. 792 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 793 message size requirements", RFC 3226, December 2001. 795 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 796 Resource Record (RR)", RFC 3445, December 2002. 798 14.2 Informative References 800 [I-D.ietf-dnsext-dns-threats] 801 Atkins, D. and R. Austein, "Threat Analysis Of The Domain 802 Name System", draft-ietf-dnsext-dns-threats-07 (work in 803 progress), April 2004. 805 [I-D.ietf-dnsext-nsec-rdata] 806 Schlyter, J., "KEY RR Secure Entry Point Flag", 807 draft-ietf-dnsext-nsec-rdata-05 (work in progress), March 808 2004. 810 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 811 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 812 April 1997. 814 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 815 Specification", RFC 2181, July 1997. 817 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 818 NCACHE)", RFC 2308, March 1998. 820 [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in 821 the Domain Name System (DNS)", RFC 2538, March 1999. 823 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 824 Wellington, "Secret Key Transaction Authentication for DNS 825 (TSIG)", RFC 2845, May 2000. 827 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 828 SIG(0)s)", RFC 2931, September 2000. 830 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 831 Update", RFC 3007, November 2000. 833 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) 834 Signing Authority", RFC 3008, November 2000. 836 [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone 837 Status", RFC 3090, March 2001. 839 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 840 (RR) Types", RFC 3597, September 2003. 842 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 843 Authenticated Data (AD) bit", RFC 3655, November 2003. 845 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 846 (RR)", RFC 3658, December 2003. 848 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 849 Signer", RFC 3755, April 2004. 851 [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure 852 Entry Point Flag", RFC 3757, April 2004. 854 Authors' Addresses 856 Roy Arends 857 Telematica Instituut 858 Drienerlolaan 5 859 7522 NB Enschede 860 NL 862 EMail: roy.arends@telin.nl 864 Rob Austein 865 Internet Systems Consortium 866 950 Charter Street 867 Redwood City, CA 94063 868 USA 870 EMail: sra@isc.org 872 Matt Larson 873 VeriSign, Inc. 874 21345 Ridgetop Circle 875 Dulles, VA 20166-6503 876 USA 878 EMail: mlarson@verisign.com 880 Dan Massey 881 USC Information Sciences Institute 882 3811 N. Fairfax Drive 883 Arlington, VA 22203 884 USA 886 EMail: masseyd@isi.edu 888 Scott Rose 889 National Institute for Standards and Technology 890 100 Bureau Drive 891 Gaithersburg, MD 20899-8920 892 USA 894 EMail: scott.rose@nist.gov 896 Intellectual Property Statement 898 The IETF takes no position regarding the validity or scope of any 899 intellectual property or other rights that might be claimed to 900 pertain to the implementation or use of the technology described in 901 this document or the extent to which any license under such rights 902 might or might not be available; neither does it represent that it 903 has made any effort to identify any such rights. Information on the 904 IETF's procedures with respect to rights in standards-track and 905 standards-related documentation can be found in BCP-11. Copies of 906 claims of rights made available for publication and any assurances of 907 licenses to be made available, or the result of an attempt made to 908 obtain a general license or permission for the use of such 909 proprietary rights by implementors or users of this specification can 910 be obtained from the IETF Secretariat. 912 The IETF invites any interested party to bring to its attention any 913 copyrights, patents or patent applications, or other proprietary 914 rights which may cover technology that may be required to practice 915 this standard. Please address the information to the IETF Executive 916 Director. 918 Full Copyright Statement 920 Copyright (C) The Internet Society (2004). All Rights Reserved. 922 This document and translations of it may be copied and furnished to 923 others, and derivative works that comment on or otherwise explain it 924 or assist in its implementation may be prepared, copied, published 925 and distributed, in whole or in part, without restriction of any 926 kind, provided that the above copyright notice and this paragraph are 927 included on all such copies and derivative works. However, this 928 document itself may not be modified in any way, such as by removing 929 the copyright notice or references to the Internet Society or other 930 Internet organizations, except as needed for the purpose of 931 developing Internet standards in which case the procedures for 932 copyrights defined in the Internet Standards process must be 933 followed, or as required to translate it into languages other than 934 English. 936 The limited permissions granted above are perpetual and will not be 937 revoked by the Internet Society or its successors or assignees. 939 This document and the information contained herein is provided on an 940 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 941 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 942 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 943 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 944 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 946 Acknowledgment 948 Funding for the RFC Editor function is currently provided by the 949 Internet Society.