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