idnits 2.17.1 draft-ietf-dnsext-dnssec-intro-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (September 16, 2003) is 7525 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 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-07) exists of draft-ietf-dnsext-dns-threats-03 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-dns-threats (ref. 'I-D.ietf-dnsext-dns-threats') == Outdated reference: A later version (-12) exists of draft-ietf-dnsext-keyrr-key-signing-flag-08 == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-04 == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-02 -- Obsolete informational reference (is this intentional?): RFC 2538 (Obsoleted by RFC 4398) -- 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) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 5 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: March 16, 2004 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 September 16, 2003 14 DNS Security Introduction and Requirements 15 draft-ietf-dnsext-dnssec-intro-06 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 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) 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 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 . . . . . . . . . . . . . . . . . . . . 23 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], 3225 [RFC3225], 3226 98 [RFC3226], and 3445 [RFC3445], as well as several works in progress: 99 "Redefinition of the AD bit" [I-D.ietf-dnsext-ad-is-secure], and 100 "Delegation Signer Resource Record" 101 [I-D.ietf-dnsext-delegation-signer]. 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 authentication chain: In the DNSSEC model, a DNSKEY RR signs a DS RR, 110 which hashes one RR in another DNSKEY RRset, which in turn signs 111 another DS RR, which hashes one RR in yet another DNSKEY RRset, 112 and so forth, finally ending, if all goes well, with a DNSKEY RR 113 which signs whatever DNS data the end user was looking for in the 114 first place. This alternating succession of DNSKEY RRsets and DS 115 RRs forms a chain of signed data, with each link in the chain 116 vouching for the next. If a signature somewhere in this chain has 117 been generated by an authentication key known to a security-aware 118 resolver, then the resolver can attempt to verify and authenticate 119 the signed chain of DNSKEY and DS RRs from that point down to the 120 target data. 122 authentication key: A public key which a security-aware resolver 123 trusts and can therefore use to verify data. A security-aware 124 resolver can discover trusted authentication keys in three ways. 125 First, the resolver is generally preconfigured to know about at 126 least one key which it should trust. This is either the key 127 itself, or a hash of the key as found in the DS RR. Second, the 128 resolver may be able to discover both a new key and an associated 129 DS RR which contains a valid hash of the new key and which has 130 been signed by a key which the resolver trusts. Third, the 131 resolver may be able to determine that a new key has been signed 132 by another key which the resolver trusts. Note that the resolver 133 must always be guided by local policy when deciding whether to 134 trust a new key, even if the local policy is simply to trust any 135 new key for which the resolver is able verify the signature. 137 island of security: Term used to describe a signed, delegated zone 138 that does not have an authentication chain from its delegating 139 parent. That is, there is no DS RR with the island's key in its 140 delegating parent zone (see [I-D.ietf-dnsext-dnssec-records]). An 141 island of security is served by a security-aware nameserver and 142 may provide authentication chains to any delegated child zones. 143 Responses from an island of security or its decendents can only be 144 validated if its zone key can be obtained by some trusted means 145 out of band from the DNS protocol. 147 key signing key: An authentication key which is used to sign one or 148 more other authentication keys. Typically, a key signing key will 149 sign a zone signing key, which in turn will sign other zone data. 150 Local policy may require the zone signing key to be changed 151 frequently, while the key signing key may have a longer validity 152 period in order to provide a more stable secure entry point into 153 the zone. Designating an authentication key as a key signing key 154 is purely an operational issue: DNSSEC validation does not 155 distinguish between key signing keys and other DNSSEC 156 authentication keys. Key signing keys are discussed in more 157 detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. 159 security-aware name server: An entity acting in the role of a name 160 server (defined in section 2.4 of [RFC1034]) which understands the 161 DNS security extensions defined in this document set. In 162 particular, a security-aware name server is an entity which 163 receives DNS queries, sends DNS responses, supports the EDNS0 164 [RFC2671] message size extension and the DO bit [RFC3225], and 165 supports the RR types and message header bits defined in this 166 document set. 168 security-aware recursive name server: An entity which acts in both 169 the security-aware name server and security-aware resolver roles. 170 A more cumbersome equivalent phrase would be "a security-aware 171 name server which offers recursive service". 173 security-aware resolver: An entity acting in the role of a resolver 174 (defined in section 2.4 of [RFC1034]) which understands the DNS 175 security extensions defined in this document set. In particular, 176 a security-aware resolver is an entity which sends DNS queries, 177 receives DNS responses, supports the EDNS0 [RFC2671] message size 178 extension and the DO bit [RFC3225], and is capable of using the RR 179 types and message header bits defined in this document set to 180 provide DNSSEC services. 182 security-aware stub resolver: An entity acting in the role of a 183 resolver (defined in section 2.4 of [RFC1034]) which has at least 184 a minimal understanding the DNS security extensions defined in 185 this document set, but which trusts one or more security-aware 186 recursive name servers to perform most of the tasks discussed in 187 this document set on its behalf. In particular, a security-aware 188 stub resolver is an entity which sends DNS queries, receives DNS 189 responses, and is capable of establishing an appropriately secured 190 channel to a security-aware recursive name server which will 191 provide these services on behalf of the security-aware stub 192 resolver. Note that the distinction between security-aware 193 resolvers and security-aware stub resolvers is different from the 194 distinction between iterative-mode and recursive-mode resolvers in 195 the base DNS specification: a particular security-aware resolver 196 may operate exclusively in recursive mode, but still perform its 197 own DNSSEC signature validity checks, while a security-aware stub 198 resolver does not, by definition. 200 security-oblivious (server or resolver): The opposite of 201 "security-aware". 203 signed zone: A zone whose RRsets are signed and which contains 204 properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS 205 records. 207 unsigned zone: The opposite of a "signed zone". 209 zone signing key: An authentication key which is used to sign a zone. 210 See key signing key, above. Typically a zone signing key will be 211 part of the same DNSKEY RRset as the key signing key which signs 212 it, but is used for a slightly different purpose and may differ 213 from the key signing key in other ways, such as validity lifetime. 215 3. Services Provided by DNS Security 217 The Domain Name System (DNS) security extensions provide origin 218 authentication and integrity assurance services for DNS data, 219 including mechanisms for authenticated denial of existence of DNS 220 data. These mechanisms are described below. 222 These mechanisms require changes to the DNS protocol. DNSSEC adds 223 four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two 224 new message header bits (CD and AD). In order to support the larger 225 DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also 226 requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support 227 for the DO bit [RFC3225], so that a security-aware resolver can 228 indicate in its queries that it wishes to receive DNSSEC RRs in 229 response messages. 231 These services protect against most of the threats to the Domain Name 232 System described in [I-D.ietf-dnsext-dns-threats]. 234 3.1 Data Origin Authentication and Data Integrity 236 DNSSEC provides authentication by associating cryptographically 237 generated digital signatures with DNS RRsets. These digital 238 signatures are stored in a new resource record, the RRSIG record. 239 Typically, there will be a single private key that signs a zone's 240 data, but multiple keys are possible: for example, there may be keys 241 for each of several different digital signature algorithms. If a 242 security-aware resolver reliably learns a zone's public key, it can 243 authenticate that zone's signed data. An important DNSSEC concept is 244 that the key that signs a zone's data is associated with the zone 245 itself and not with the zone's authoritative name servers (public 246 keys for DNS transaction authentication mechanisms may also appear in 247 zones, as described in [RFC2931], but DNSSEC itself is concerned with 248 object security of DNS data, not channel security of DNS 249 transactions). 251 A security-aware resolver can learn a zone's public key either by 252 having the key preconfigured into the resolver or by normal DNS 253 resolution. To allow the latter, public keys are stored in a new 254 type of resource record, the DNSKEY RR. Note that the private keys 255 used to sign zone data must be kept secure, and should be stored 256 offline when practical to do so. To discover a public key reliably 257 via DNS resolution, the target key itself needs to be signed by 258 either a preconfigured authentication key or another key that has 259 been authenticated previously. Security-aware resolvers authenticate 260 zone information by forming an authentication chain from a newly 261 learned public key back to a previously known authentication public 262 key, which in turn either must have been preconfigured into the 263 resolver or must have been learned and verified previously. 264 Therefore, the resolver must be configured with at least one public 265 key or hash of a trusted key: if the preconfigured key is a zone 266 signing key, then it will authenticate the associated zone; if the 267 preconfigured key is a key signing key, it will authenticate a zone 268 signing key. If the resolver has been preconfigured with the hash of 269 a key rather than the key itself, the resolver may need to obtain the 270 key via a DNS query. To help security-aware resolvers establish this 271 authentication chain, security-aware name servers attempt to send the 272 signature(s) needed to authenticate a zone's public key in the DNS 273 reply message along with the public key itself, provided there is 274 space available in the message. 276 The authentication chain specified in the original DNS security 277 extensions proceeded from signed KEY record to signed KEY record, as 278 necessary, and finally to the queried RRset. The current 279 specification adds a new Delegation Signer (DS) RR type to simplify 280 some of the administrative tasks involved in signing delegations 281 across organizational boundaries. The DS RRset resides at a 282 delegation point in a parent zone and indicates the key or keys used 283 by the delegated child zone to self-sign the DNSKEY RRset at the 284 child zone's apex. The child zone, in turn, uses one or more of the 285 keys in this DNSKEY RRset to sign its zone data. The authentication 286 chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes 287 zero or more DS->DNSKEY subchains. 289 A security-aware resolver normally constructs this authentication 290 chain from the root of the DNS hierarchy down to the leaf zones based 291 on preconfigured knowledge of the public key for the root. Local 292 policy, however, may also allow a security-aware resolver to trust 293 one or more preconfigured keys (or key hashes) other than the root 294 key, or may not provide preconfigured knowledge of the root key, or 295 may prevent the resolver from trusting particular keys for arbitrary 296 reasons even if those keys are properly signed with verifiable 297 signatures. DNSSEC provides mechanisms by which a security-aware 298 resolver can determine whether an RRset's signature is "valid" within 299 the meaning of DNSSEC, but trust, in the final analysis, is a matter 300 of local policy, which may extend or even override the protocol 301 extensions defined in this document set. 303 3.2 Authenticating Name and Type Non-Existence 305 The security mechanism described in Section 3.1 only provides a way 306 to sign existing RRsets in a zone. The problem of providing negative 307 responses with the same level of authentication and integrity 308 requires the use of another new resource record type, the NSEC 309 record. The NSEC record allows a security-aware resolver to 310 authenticate a negative reply for either name or type non-existence 311 via the same mechanisms used to authenticate other DNS replies. Use 312 of NSEC records require a canonical representation and ordering for 313 domain names in zones. Chains of NSEC records explicitly describe 314 the gaps, or "empty space", between domain names in a zone, as well 315 as listing the types of RRsets present at existing names. Each NSEC 316 record is signed and authenticated using the mechanisms described in 317 Section 3.1. 319 4. Services Not Provided by DNS Security 321 DNS was originally designed with the assumptions that the DNS will 322 return the same answer to any given query regardless of who may have 323 issued the query, and that all data in the DNS is thus visible. 324 Accordingly, DNSSEC is not designed to provide confidentiality, 325 access control lists, or other means of differentiating between 326 inquirers. 328 DNSSEC provides no protection against denial of service attacks. 329 Security-aware resolvers and security-aware name servers are 330 vulnerable to an additional class of denial of service attacks based 331 on cryptographic operations. Please see Section 11 for details. 333 The DNS security extensions provide data and origin authentication 334 for DNS data. The mechanisms outlined above extend no protection to 335 operations such as zone transfers and dynamic update [RFC3007]. 336 Message authentication schemes described in [RFC2845] and [RFC2931] 337 address security operations that pertain to these transactions. This 338 includes the use of KEY and SIG resource records for message 339 authentication. 341 5. Resolver Considerations 343 A security-aware resolver needs to be able to perform cryptographic 344 functions necessary to verify digital signatures using at least the 345 mandatory-to-implement algorithms. Security-aware resolvers must 346 also be capable of forming a authentication chain from a newly 347 learned zone back to a authentication key, as described above. This 348 process might require additional queries to intermediate DNS zones to 349 obtain necessary DNSKEY, DS and RRSIG records. A security-aware 350 resolver should be configured with at least one authentication key or 351 a key's DS RR hash as the starting point from which it will attempt 352 to establish authentication chains. 354 If a security-aware resolver is separated from the relevant 355 authoritative name servers by a recursive name server or by any sort 356 of device which acts as a proxy for DNS, and if the recursive name 357 server or proxy is not security-aware, the security-aware resolver 358 may not be able to operate in a secure mode. For example, if a 359 security-aware resolver's packets are routed through a network 360 address translation device that includes a DNS proxy which is not 361 security-aware, the security-aware resolver may find it difficult or 362 impossible to obtain or validate signed DNS data. 364 If a security-aware resolver must rely on an unsigned zone or a name 365 server that is not security aware, the resolver may not be able to 366 validate DNS responses, and will need a local policy on whether to 367 accept unverified responses. 369 A security-aware resolver should take a signature's validation period 370 into consideration when determining the TTL of data in its cache, to 371 avoid caching signed data beyond the validity period of the 372 signature, but should also allow for the possibility that the 373 security-aware resolver's own clock is wrong. Thus, a security-aware 374 resolver which is part of a security-aware recursive name server will 375 need to pay careful attention to the DNSSEC "checking disabled" (CD) 376 bit [I-D.ietf-dnsext-dnssec-records] in order to avoid blocking valid 377 signatures from getting through to other security-aware resolvers 378 which are clients of this recursive name server and which are capable 379 of performing their own DNSSEC validity checks. See 380 [I-D.ietf-dnsext-dnssec-protocol] for how a secure recursive server 381 handles queries with the CD bit set. 383 6. Stub Resolver Considerations 385 Although not strictly required to do so by the protocol, most DNS 386 queries originate from stub resolvers. Stub resolvers, by 387 definition, are minimal DNS resolvers which use recursive query mode 388 to offload most of the work of DNS resolution to a recursive name 389 server. Given the widespread use of stub resolvers, the DNSSEC 390 architecture has to take stub resolvers into account, but the 391 security features needed in a stub resolver differ in some respects 392 from those needed in a full security-aware resolver. 394 Even an unaugmented stub resolver may get some benefit from DNSSEC if 395 the recursive name servers it uses are security-aware, but for the 396 stub resolver to place any real reliance on DNSSEC services, the stub 397 resolver must trust both the recursive name servers in question and 398 the communication channels between itself and those name servers. 399 The first of these issues is a local policy issue: in essence, a stub 400 resolver has no real choice but to place itself at the mercy of the 401 recursive name servers that it uses, since it does not perform DNSSEC 402 validity checks on its own. The second issue requires some kind of 403 channel security mechanism; proper use of DNS transaction 404 authentication mechanisms such as SIG(0) or TSIG would suffice, as 405 would appropriate use of IPsec, and particular implementations may 406 have other choices available, such as operating system specific 407 interprocess communication mechanisms. Confidentiality is not needed 408 for this channel, but data integrity and message authentication are. 410 A security-aware stub resolver which does trust both its recursive 411 name servers and its communication channel to them may chose to 412 examine the setting of the AD bit in the message header of the 413 response messages it receives to find out whether the recursive name 414 server was able to validate signatures for all of the data in the 415 Answer and Authority sections of the response. 417 There is one more step which a security-aware stub resolver can take 418 if, for whatever reason, it is not able to establish a useful trust 419 relationship with the recursive name servers which it uses: it can 420 perform its own signature validation, by setting the Checking 421 Disabled (CD) bit in its query messages. Upon taking this step, the 422 resolver is no longer really a stub resolver at all anymore (in the 423 terminology used in this document set, anyway), and is now a 424 security-aware resolver with somewhat limited functionality. 426 7. Zone Considerations 428 There are several differences between signed and unsigned zones. A 429 signed zone will contain additional security-related records (RRSIG, 430 DNSKEY, DS and NSEC records). RRSIG and NSEC records may be 431 generated by a signing process prior to serving the zone. The RRSIG 432 records that accompany zone data have defined inception and 433 expiration times, which establish a validity period for the 434 signatures and the zone data the signatures cover. 436 7.1 TTL values vs. RRSIG validity period 438 It is important to note the distinction between an RRset's TTL value 439 and the signature validity period specified by the RRSIG RR covering 440 that RRset. DNSSEC does not change the definition or function of the 441 TTL value, which is intended to maintain database coherency in 442 caches. A caching resolver purges RRsets from its cache no later than 443 the end of the time period specified by the TTL fields of those 444 RRsets, regardless of whether or not the resolver is security-aware. 446 The inception and expiration fields in the RRSIG RR 447 [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time 448 period during which the signature can be used to validate the RRset 449 that it covers. The signatures associated with signed zone data are 450 only valid for the time period specified by these fields in the RRSIG 451 RRs in question. TTL values cannot extend the validity period of 452 signed RRsets in a resolver's cache, but the resolver may use the 453 time remaining before expiration of the signature validity period of 454 a signed RRset as an upper bound for the TTL of the signed RRset and 455 its associated RRSIG RR in the resolver's cache. 457 7.2 New Temporal Dependency Issues for Zones 459 Information in a signed zone has a temporal dependency which did not 460 exist in the original DNS protocol. A signed zone requires regular 461 maintenance to ensure that each RRset in the zone has a current valid 462 RRSIG RR. The signature validity period of a RRSIG RR is a interval 463 during which the signature for one particular signed RRset can be 464 considered valid, and the signatures of different RRsets in a zone 465 may expire at different times. Re-signing one or more RRsets in a 466 zone will change one or more RRSIG RRs, which in turn will require 467 incrementing the zone's SOA serial number to indicate that a zone 468 change has occurred and re-signing the SOA RRset itself. Thus, 469 re-signing any RRset in a zone may also trigger DNS NOTIFY messages 470 and zone transfers operations. 472 8. Name Server Considerations 474 A security-aware name server should include the appropriate DNSSEC 475 records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from 476 resolvers which have signaled their willingness to receive such 477 records via use of the DO bit in the EDNS header, subject to message 478 size limitations. For this reason a security-aware name server must 479 support the EDNS mechanism size extension, since otherwise inclusion 480 of DNSSEC RRs could easily cause UDP message truncation and fallback 481 to TCP. 483 If possible, the private half of each DNSSEC key pair should be kept 484 offline, but this will not be possible for a zone for which DNS 485 dynamic update has been enabled. In the dynamic update case, the 486 primary master server for the zone will have to re-sign the zone when 487 updated, so the private half of the zone signing key will have to be 488 kept online. This is an example of a situation where the ability to 489 separate the zone's DNSKEY RRset into zone signing key(s) and key 490 signing key(s) may be useful, since the key singing key(s) in such a 491 case can still be kept offline. 493 DNSSEC, by itself, is not enough to protect the integrity of an 494 entire zone during zone transfer operations, since even a signed zone 495 contains some unsigned data if the zone has any children, so zone 496 maintenance operations will require some additional mechanisms (most 497 likely some form of channel security, such as TSIG, SIG(0), or 498 IPsec). 500 9. DNS Security Document Family 502 The DNSSEC set of documents can be partitioned into five main groups 503 as depicted in Figure 1. All these documents are in turn under the 504 larger umbrella of the DNS base protocol documents. 506 9.1 DNS Security Document Roadmap 508 +----------------------------------+ 509 | Base DNS Protocol Documents | 510 | [RFC1035, RFC2181, et sequentia] | 511 +----------------------------------+ 512 | 513 | 514 +-----------+ +----------+ 515 | DNSSEC | | New | 516 | Protocol |--------->| Security | 517 | Documents | | Uses | 518 +-----------+ +----------+ 519 | 520 | 521 +---------------- - - - - - - -+ 522 | . 523 | . 524 +------------------+ . 525 | Digital | +------------------+ 526 | Signature | | Transaction | 527 | Algorithm | | Authentication | 528 | Implementations | | Implementations | 529 +------------------+ +------------------+ 531 9.2 Categories of DNS Security Documents 533 The "DNSSEC protocol document set" refers to the three documents 534 which form the core of the DNS security extensions: 536 1. DNS Security Introduction and Requirements (this document) 538 2. Resource Records for DNS Security Extensions 539 [I-D.ietf-dnsext-dnssec-records] 541 3. Protocol Modifications for the DNS Security Extensions 542 [I-D.ietf-dnsext-dnssec-protocol] 544 The "Digital Signature Algorithm Implementations" document set refers 545 to the group of documents that describe how specific digital 546 signature algorithms should be implemented to fit the DNSSEC resource 547 record format. Each of these documents deals with a specific digital 548 signature algorithm. 550 The "Transaction Authentication Implementations" document set refers 551 to the group of documents that deal with DNS message authentication, 552 including secret key establishment and verification. While not 553 strictly part of the DNSSEC specification as defined in this set of 554 documents, this group is noted to show its relationship to DNSSEC. 556 The final document set, "New Security Uses", refers to documents that 557 seek to use proposed DNS Security extensions for other security 558 related purposes. DNSSEC does not provide any direct security for 559 these new uses, but may be used to support them. Documents that fall 560 in this category include the use of DNS in the storage and 561 distribution of certificates [RFC2538]. 563 10. IANA Considerations 565 This overview document introduces no new IANA considerations. Please 566 see [I-D.ietf-dnsext-dnssec-records] for a complete review of the 567 IANA considerations introduced by DNSSEC. 569 11. Security Considerations 571 This document introduces the DNS security extensions and describes 572 the document set that contains the new security records and DNS 573 protocol modifications. This document discusses the capabilities and 574 limitations of these extensions. The extensions provide data origin 575 authentication and data integrity using digital signatures over 576 resource record sets. 578 In order for a security-aware resolver to validate a DNS response, 579 all of the intermediate zones must be signed, and all of the 580 intermediate name servers must be security-aware, as defined in this 581 document set. A security-aware resolver cannot verify responses 582 originating from an unsigned zone, from a zone not served by a 583 security-aware name server, or for any DNS data which the resolver is 584 only able to obtain through a recursive name server which is not 585 security-aware. If there is a break in the authentication chain such 586 that a security-aware resolver cannot obtain and validate the 587 authentication keys it needs, then the security-aware resolver cannot 588 validate the affected DNS data. 590 This document briefly discusses other methods of adding security to a 591 DNS query, such as using a channel secured by IPsec or using a DNS 592 transaction authentication mechanism, but transaction security is not 593 part of DNSSEC per se. 595 A security-aware stub resolver, by definition, does not perform 596 DNSSEC signature validation on its own, and thus is vulnerable both 597 to attacks on (and by) the security-aware recursive name servers 598 which perform these checks on its behalf and also to attacks on its 599 communication with those security-aware recursive name servers. 600 Security-aware stub resolvers should use some form of channel 601 security to defend against the latter threat. The only known defense 602 against the former threat would be for the security-aware stub 603 resolver to perform its own signature validation, at which point, 604 again by definition, it would no longer be a security-aware stub 605 resolver. 607 DNSSEC does not protect against denial of service attacks. DNSSEC 608 makes DNS vulnerable to a new class of denial of service attacks 609 based on cryptographic operations against security-aware resolvers 610 and security-aware name servers, since an attacker can attempt to use 611 DNSSEC mechanisms to consume a victim's resources. This class of 612 attacks takes at least two forms. An attacker may be able to consume 613 resources in a security-aware resolver's signature validation code by 614 tampering with RRSIG RRs in response messages or by constructing 615 needlessly complex signature chains. An attacker may also be able to 616 consume resources in a security-aware name server which supports DNS 617 dynamic update, by sending a stream of update messages that force the 618 security-aware name server to re-sign some RRsets in the zone more 619 frequently than would otherwise be necessary. 621 DNSSEC add the ability for a hostile party to enumerate all the names 622 in a zone by following the NSEC chain. NSEC RRs assert which names 623 do not exist in a zone by linking from existing name to existing name 624 along a canonical ordering of all the names within a zone. Thus, an 625 attacker can query these NSEC RRs in sequence to obtain all the names 626 in a zone. While not an attack on the DNS itself, this could allow 627 an attacker to map network hosts or other resources by enumerating 628 the contents of a zone. 630 DNSSEC does not provide confidentiality, due to a deliberate design 631 choice. 633 DNSSEC does not protect against tampering with unsigned zone data. 634 Non-authoritative data at zone cuts (glue and NS RRs in the parent 635 zone) are not signed. Thus, while DNSSEC can provide data origin 636 authentication and data integrity for RRsets, it cannot do so for 637 zones, and other mechanisms must be used to protect zone transfer 638 operations. 640 12. Acknowledgements 642 This document was created from the input and ideas of several members 643 of the DNS Extensions Working Group. The authors would like to 644 acknowledge (in alphabetical order) the following people for their 645 contributions and comments on this document: Derek Atkins, Donald 646 Eastlake, Miek Gieben, Olafur Gudmundsson, Olaf Kolkman, Ed Lewis, 647 Ted Lindgreen, Bill Manning, and Brian Wellington. 649 Normative References 651 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 652 STD 13, RFC 1034, November 1987. 654 [RFC1035] Mockapetris, P., "Domain names - implementation and 655 specification", STD 13, RFC 1035, November 1987. 657 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 658 RFC 2535, March 1999. 660 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 661 2671, August 1999. 663 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 664 Wellington, "Secret Key Transaction Authentication for DNS 665 (TSIG)", RFC 2845, May 2000. 667 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 668 SIG(0)s)", RFC 2931, September 2000. 670 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 671 3225, December 2001. 673 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 674 message size requirements", RFC 3226, December 2001. 676 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 677 Resource Record (RR)", RFC 3445, December 2002. 679 [I-D.ietf-dnsext-dns-threats] 680 Atkins, D. and R. Austein, "Threat Analysis Of The Domain 681 Name System", draft-ietf-dnsext-dns-threats-03 (work in 682 progress), June 2003. 684 [I-D.ietf-dnsext-keyrr-key-signing-flag] 685 Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure 686 Entry Point (SEP) Flag", 687 draft-ietf-dnsext-keyrr-key-signing-flag-08 (work in 688 progress), July 2003. 690 [I-D.ietf-dnsext-dnssec-records] 691 Arends, R., Austein, R., Larson, M., Massey, D. and S. 692 Rose, "Resource Records for DNS Security Extensions", 693 draft-ietf-dnsext-dnssec-records-04 (work in progress), 694 September 2003. 696 [I-D.ietf-dnsext-dnssec-protocol] 697 Arends, R., Austein, R., Larson, M., Massey, D. and S. 698 Rose, "Protocol Modifications for the DNS Security 699 Extensions", draft-ietf-dnsext-dnssec-protocol-02 (work in 700 progress), September 2003. 702 Informative References 704 [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in 705 the Domain Name System (DNS)", RFC 2538, March 1999. 707 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 708 Update", RFC 3007, November 2000. 710 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) 711 Signing Authority", RFC 3008, November 2000. 713 [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone 714 Status", RFC 3090, March 2001. 716 [I-D.ietf-dnsext-ad-is-secure] 717 Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD 718 bit", draft-ietf-dnsext-ad-is-secure-06 (work in 719 progress), June 2002. 721 [I-D.ietf-dnsext-delegation-signer] 722 Gudmundsson, O., "Delegation Signer Resource Record", 723 draft-ietf-dnsext-delegation-signer-15 (work in progress), 724 June 2003. 726 Authors' Addresses 728 Roy Arends 729 Telematica Instituut 730 Drienerlolaan 5 731 7522 NB Enschede 732 NL 734 EMail: roy.arends@telin.nl 736 Rob Austein 737 Internet Software Consortium 738 40 Gavin Circle 739 Reading, MA 01867 740 USA 742 EMail: sra@isc.org 743 Matt Larson 744 VeriSign, Inc. 745 21345 Ridgetop Circle 746 Dulles, VA 20166-6503 747 USA 749 EMail: mlarson@verisign.com 751 Dan Massey 752 USC Information Sciences Institute 753 3811 N. Fairfax Drive 754 Arlington, VA 22203 755 USA 757 EMail: masseyd@isi.edu 759 Scott Rose 760 National Institute for Standards and Technology 761 100 Bureau Drive 762 Gaithersburg, MD 20899-8920 763 USA 765 EMail: scott.rose@nist.gov 767 Intellectual Property Statement 769 The IETF takes no position regarding the validity or scope of any 770 intellectual property or other rights that might be claimed to 771 pertain to the implementation or use of the technology described in 772 this document or the extent to which any license under such rights 773 might or might not be available; neither does it represent that it 774 has made any effort to identify any such rights. Information on the 775 IETF's procedures with respect to rights in standards-track and 776 standards-related documentation can be found in BCP-11. Copies of 777 claims of rights made available for publication and any assurances of 778 licenses to be made available, or the result of an attempt made to 779 obtain a general license or permission for the use of such 780 proprietary rights by implementors or users of this specification can 781 be obtained from the IETF Secretariat. 783 The IETF invites any interested party to bring to its attention any 784 copyrights, patents or patent applications, or other proprietary 785 rights which may cover technology that may be required to practice 786 this standard. Please address the information to the IETF Executive 787 Director. 789 Full Copyright Statement 791 Copyright (C) The Internet Society (2003). All Rights Reserved. 793 This document and translations of it may be copied and furnished to 794 others, and derivative works that comment on or otherwise explain it 795 or assist in its implementation may be prepared, copied, published 796 and distributed, in whole or in part, without restriction of any 797 kind, provided that the above copyright notice and this paragraph are 798 included on all such copies and derivative works. However, this 799 document itself may not be modified in any way, such as by removing 800 the copyright notice or references to the Internet Society or other 801 Internet organizations, except as needed for the purpose of 802 developing Internet standards in which case the procedures for 803 copyrights defined in the Internet Standards process must be 804 followed, or as required to translate it into languages other than 805 English. 807 The limited permissions granted above are perpetual and will not be 808 revoked by the Internet Society or its successors or assignees. 810 This document and the information contained herein is provided on an 811 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 812 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 813 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 814 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 815 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 817 Acknowledgement 819 Funding for the RFC Editor function is currently provided by the 820 Internet Society.