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