idnits 2.17.1 draft-ietf-dnsext-dnssec-intro-05.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 14, 2003) is 7736 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) == Unused Reference: '6' is defined on line 646, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 655, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 658, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. '3') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (ref. '4') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (ref. '5') (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 3445 (ref. '10') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-07) exists of draft-ietf-dnsext-dns-threats-02 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-dns-threats (ref. '11') == Outdated reference: A later version (-12) exists of draft-ietf-dnsext-keyrr-key-signing-flag-05 == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-02 == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 2538 (ref. '15') (Obsoleted by RFC 4398) == Outdated reference: A later version (-07) exists of draft-ietf-dnsext-dnssec-roadmap-06 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 3 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 15, 2003 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 February 14, 2003 14 DNS Security Introduction and Requirements 15 draft-ietf-dnsext-dnssec-intro-05 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 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 15, 2003. 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 The Domain Name System Security Extensions (DNSSEC) add data origin 47 authentication and data integrity to the Domain Name System. This 48 document introduces these extensions, and describes their 49 capabilities and limitations. This document also discusses the 50 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 . . . . . . . . . . . . . . 6 59 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 6 60 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 7 61 4. Services Not Provided by DNS Security . . . . . . . . . . . . 9 62 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 10 63 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 11 64 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 7.1 TTL values vs. SIG validity period . . . . . . . . . . . . . . 12 66 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 12 67 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 13 68 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 14 69 9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 14 70 9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 14 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 74 Normative References . . . . . . . . . . . . . . . . . . . . . 20 75 Informative References . . . . . . . . . . . . . . . . . . . . 21 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 77 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23 79 1. Introduction 81 This document introduces the Domain Name System Security Extensions 82 (DNSSEC). This document and its two companion documents ([13] and 83 [14]) update, clarify, and refine the security extensions originally 84 defined in RFC 2535 [3]. These security extensions consist of a set 85 of new resource record types and modifications to the existing DNS 86 protocol [2]. The new records and protocol modifications are not 87 fully described in this document, but are described in a family of 88 documents outlined in Section 9. Section 3 and Section 4 describe 89 the capabilities and limitations of the security extensions in 90 greater detail. Section 5, Section 6, Section 7, and Section 8 91 discuss the effect that these security extensions will have on 92 resolvers, stub resolvers, zones and name servers. 94 This document and its two companions update and obsolete RFCs 2535, 95 3008, 3090, 3225, 3226, and 3445, as well as several works in 96 progress: "Redefinition of the AD bit", "Delegation Signer Resource 97 Record", and "DNSSEC Opt-In". See [18] for more details on these 98 documents. 100 The DNS security extensions provide origin authentication and 101 integrity protection for DNS data, as well as a means of public key 102 distribution. These extensions do not provide protection against 103 other types of attack, nor do they provide confidentiality. 105 2. Definitions of Important DNSSEC Terms 107 authentication chain: In the DNSSEC model, a KEY RR signs a DS RR, 108 which hashes one RR in another KEY RRset, which in turn signs 109 another DS RR, which hashes one RR in yet another KEY RRset, and 110 so forth, finally ending, if all goes well, with a KEY RR which 111 signs whatever DNS data the end user was looking for in the first 112 place. This alternating succession of KEY RRsets and DS RRs forms 113 a chain of signed data, with each link in the chain vouching for 114 the next. If a signature somewhere in this chain has been 115 generated by an authentication key known to a security-aware 116 resolver, then the resolver can attempt to verify and authenticate 117 the signed chain of KEY and DS RRs from that point down to the 118 target data. 120 authentication key: A public key which a security-aware resolver 121 trusts and can therefore use to verify data. A security-aware 122 resolver can discover trusted authentication keys in three ways. 123 First, the resolver is generally preconfigured to know about at 124 least one key which it should trust. Second, the resolver may be 125 able to discover both a new key and an associated DS RR which 126 contains a valid hash of the new key and which has been signed by 127 a key which the resolver trusts. Third, the resolver may be able 128 to determine that a new key has been signed by another key which 129 the resolver trusts. Note that the resolver must always be guided 130 by local policy when deciding whether to trust a new key, even if 131 the local policy is simply to trust any new key for which the 132 resolver is able verify the signature. 134 key signing key: An authentication key which is used to sign one or 135 more other authentication keys. Typically, a key signing key will 136 sign a zone signing key, which in turn will sign other zone data. 137 Local policy may require the zone signing key to be changed 138 frequently, while the key signing key may have a longer validity 139 period in order to provide a more stable secure entry point into 140 the zone. Designating an authentication key as a key signing key 141 is purely an operational issue: DNSSEC itself does not distinguish 142 between key signing keys and other DNSSEC authentication keys. 143 Key signing keys are discussed in more detail in [12]. 145 security-aware name server: An entity acting in the role of a name 146 server (defined in section 2.4 of [1]) which understands the DNS 147 security extensions defined in this document set. In particular, 148 a security-aware name server is an entity which receives DNS 149 queries, sends DNS responses, supports the EDNS0 [4] message size 150 extension and the DO bit [8], and supports the RR types and 151 message header bits defined in this document set. 153 security-aware recursive name server: An entity which acts in both 154 the security-aware name server and security-aware resolver roles. 155 A more cumbersome equivalent phrase would be "a security-aware 156 name server which offers recursive service". 158 security-aware resolver: An entity acting in the role of a resolver 159 (defined in section 2.4 of [1]) which understands the DNS security 160 extensions defined in this document set. In particular, a 161 security-aware resolver is an entity which sends DNS queries, 162 receives DNS responses, supports the EDNS0 [4] message size 163 extension and the DO bit [8], and is capable of using the RR types 164 and message header bits defined in this document set to provide 165 DNSSEC services. 167 security-aware stub resolver: An entity acting in the role of a 168 resolver (defined in section 2.4 of [1]) which has at least a 169 minimal understanding the DNS security extensions defined in this 170 document set, but which trusts one or more security-aware 171 recursive name servers to perform most of the tasks discussed in 172 this document set on its behalf. In particular, a security-aware 173 stub resolver is an entity which sends DNS queries, receives DNS 174 responses, and is capable of establishing an appropriately secured 175 channel to a security-aware recursive name server which will 176 provide these services on behalf of the security-aware stub 177 resolver. Note that the distinction between security-aware 178 resolvers and security-aware stub resolvers is different from the 179 distinction between iterative-mode and recursive-mode resolvers in 180 the base DNS specification: a particular security-aware resolver 181 may operate exclusively in recursive mode, but still performs its 182 own DNSSEC signature validity checks, while a security-aware stub 183 resolver does not, by definition. 185 security-oblivious: The opposite of "security-aware". 187 signed zone: A zone whose RRsets are signed and which contains 188 properly constructed KEY, SIG, NXT and (optionally) DS records. 190 unsigned zone: The opposite of a "signed zone". 192 zone signing key: An authentication key which is used to sign a zone. 193 See key signing key, above. Typically a zone signing key will be 194 part of the same KEY RRset as the key signing key which signs it, 195 but is used for a slightly different purpose and may differ from 196 the key signing key in other ways, such as validity lifetime. 198 3. Services Provided by DNS Security 200 The Domain Name System (DNS) security extensions provide origin 201 authentication and integrity assurance services for DNS data, 202 including mechanisms for authenticated denial of existence of DNS 203 data. These mechanisms are described below. 205 These mechanisms require minor changes to the DNS protocol. DNSSEC 206 adds four new resource record types (SIG, KEY, DS and NXT) and two 207 new message header bits (CD and AD). In order to support the larger 208 DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also 209 requires EDNS0 support [4]. Finally, DNSSEC requires support for the 210 DO bit [8], so that a security-aware resolver can indicate in its 211 queries that it wishes to receive DNSSEC RRs in response messages. 213 These services protect against most of the threats to the Domain Name 214 System described in [11]. 216 3.1 Data Origin Authentication and Data Integrity 218 DNSSEC provides authentication by associating cryptographically 219 generated digital signatures with DNS RRsets. These digital 220 signatures are stored in a new resource record, the SIG record. 221 Typically, there will be a single private key that signs a zone's 222 data, but multiple keys are possible: for example, there may be keys 223 for each of several different digital signature algorithms. If a 224 security-aware resolver reliably learns a zone's public key, it can 225 authenticate that zone's signed data. An important DNSSEC concept is 226 that the key that signs a zone's data is associated with the zone 227 itself and not with the zone's authoritative name servers (public 228 keys for DNS transaction authentication mechanisms may also appear in 229 zones, as described in [7], but DNSSEC itself is concerned with 230 object security of DNS data, not channel security of DNS 231 transactions). 233 A security-aware resolver can learn a zone's public key either by 234 having the key preconfigured into the resolver or by normal DNS 235 resolution. To allow the latter, public keys are stored in a new 236 type of resource record, the KEY RR. Note that the private keys used 237 to sign zone data must be kept secure, and should be stored offline 238 when practical to do so. To discover a public key reliably via DNS 239 resolution, the target key itself needs to be signed by either a 240 preconfigured authentication key or another key that has been 241 authenticated previously. Security-aware resolvers authenticate zone 242 information by forming an authentication chain from a newly learned 243 public key back to a previously known authentication public key, 244 which in turn either must have been preconfigured into the resolver 245 or must have been learned and verified previously. Therefore, the 246 resolver must be configured with at least one public key: if the 247 preconfigured key is a zone signing key, then it will authenticate 248 the associated zone; if the preconfigured key is a key signing key, 249 it will authenticate a zone signing key. To help security-aware 250 resolvers establish this authentication chain, security-aware name 251 servers attempt to send the signature(s) needed to authenticate a 252 zone's public key in the DNS reply message along with the public key 253 itself, provided there is space available in the message. 255 The authentication chain specified in the original DNS security 256 extensions proceeded from signed KEY record to signed KEY record, as 257 necessary, and finally to the queried RRset. The current 258 specification adds a new Delegation Signer (DS) RR type to simplify 259 some of the administrative tasks involved in signing delegations 260 across organizational boundaries. The DS RRset resides at a 261 delegation point in a parent zone and indicates the key or keys used 262 by the delegated child zone to self-sign the KEY RRset at the child 263 zone's apex. The child zone, in turn, uses one or more of the keys 264 in this KEY RRset to sign its zone data. The authentication chain is 265 therefore KEY->[DS->KEY]*->RRset, where "*" denotes zero or more DS- 266 >KEY subchains. 268 This authentication chain is normally constructed from the root of 269 the DNS hierarchy down to the leaf zones, and is normally based on 270 preconfigured knowledge of the public key for the root. Local 271 policy, however, may also allow a security-aware resolver to trust 272 one or more preconfigured keys other than the root key, or may not 273 provide preconfigured knowledge of the root key, or may even prevent 274 the resolver from trusting particular keys for arbitrary reasons even 275 if those keys are properly signed with verifiable signatures. DNSSEC 276 provides mechanisms by which a security-aware resolver can determine 277 whether an RRset's signature is "valid" within the meaning of DNSSEC, 278 but authentication and trust, in the final analysis, are matters of 279 local policy, which may extend or even override the protocol 280 extensions defined in this document set. 282 3.2 Authenticating Name and Type Non-Existence 284 The security mechanism described in Section 3.1 only provides a way 285 to sign existing RRsets in a zone. The problem of providing negative 286 responses with the same level of authentication and integrity 287 requires the use of another new resource record type, the NXT record. 288 The NXT record allows a security-aware resolver to authenticate a 289 negative reply for either name or type non-existence via the same 290 mechanisms used to authenticate other DNS replies. Use of NXT 291 records require a canonical representation and ordering for domain 292 names in zones. Chains of NXT records explicitly describe the gaps, 293 or "empty space", between domain names in a zone, as well as listing 294 the types of RRsets present at existing names. Each NXT record is 295 signed and authenticated using the mechanisms described in Section 296 3.1. 298 4. Services Not Provided by DNS Security 300 DNS was originally designed with the assumptions that the DNS will 301 return the same answer to any given query regardless of who may have 302 issued the query, and that all data in the DNS is thus visible. 303 Accordingly, DNSSEC is not designed to provide confidentiality, 304 access control lists, or other means of differentiating between 305 inquirers. 307 DNSSEC provides no protection against denial of service attacks. 308 Security-aware resolvers and security-aware name servers are 309 vulnerable to an additional class of denial of service attacks based 310 on cryptographic operations. Please see Section 11 for details. 312 The DNS security extensions provide data and origin authentication 313 for DNS data. The mechanisms outlined above extend no protection to 314 operations such as zone transfers and dynamic update [16]. Message 315 authentication schemes described in [5] and [7] address security 316 operations that pertain to these transactions. 318 5. Resolver Considerations 320 A security-aware resolver needs to be able to perform necessary 321 cryptographic functions to verify digital signatures using at least 322 the mandatory-to-implement algorithms. Security-aware resolvers must 323 also be capable of forming a authentication chain from a newly 324 learned zone back to a authentication key, as described above. This 325 process might require additional queries to intermediate DNS zones to 326 obtain necessary KEY, DS and SIG records. A security-aware resolver 327 should be configured with at least one authentication key as the 328 starting point from which it will attempt to establish authentication 329 chains. 331 If a security-aware resolver is separated from the relevant 332 authoritative name servers by a recursive name server or by any sort 333 of device which acts as a proxy for DNS, and if the recursive name 334 server or proxy is not security-aware, the security-aware resolver 335 may not be able to operate in a secure mode. For example, if a 336 security-aware resolver's packets are routed through a network 337 address translation device that includes a DNS proxy which is not 338 security-aware the security-aware resolver may find it difficult or 339 impossible to obtain or validate signed DNS data. 341 If a security-aware resolver must rely on an unsigned zone or a name 342 server that is not security aware, the resolver may not be able to 343 validate DNS responses, and will need a local policy on whether to 344 accept unverified responses. 346 A security-aware resolver should take a signature's validation period 347 into consideration when determining the TTL of data in its cache, to 348 avoid caching signed data beyond the validity period of the 349 signature, but should also allow for the possibility that the 350 security-aware resolver's own clock is wrong. Thus, a security-aware 351 resolver which is part of a security-aware recursive name server will 352 need to pay careful attention to the DNSSEC "checking disabled" (CD) 353 bit [13] in order to avoid blocking valid signatures from getting 354 through to other security-aware resolvers which are clients of this 355 recursive name server and which are capable of performing their own 356 DNSSEC validity checks. 358 6. Stub Resolver Considerations 360 Although not strictly required to do so by the protocol, most DNS 361 queries originate from stub resolvers. Stub resolvers, by 362 definition, are minimal DNS resolvers which use recursive query mode 363 to offload most of the work of DNS resolution to a recursive name 364 server. Given the widespread use of stub resolvers, the DNSSEC 365 architecture has to take stub resolvers into account, but the 366 security features needed in a stub resolver differ in some respects 367 from those needed in a full security-aware resolver. 369 Even an unaugmented stub resolver may get some benefit from DNSSEC if 370 the recursive name servers it uses are security-aware, but for the 371 stub resolver to place any real reliance on DNSSEC services, the stub 372 resolver must trust both the recursive name servers in question and 373 the communication channels between itself and those name servers. 374 The first of these issues is a local policy issue: in essence, a stub 375 resolver has no real choice but to place itself at the mercy of the 376 recursive name servers that it uses, since it does not perform DNSSEC 377 validity checks on its own. The second issue requires some kind of 378 channel security mechanism; proper use of DNS transaction 379 authentication mechanisms such as SIG(0) or TSIG would suffice, as 380 would appropriate use of IPsec, and particular implementations may 381 have other choices available, such as operating system specific 382 interprocess communication mechanisms. Confidentiality is not needed 383 for this channel, but data integrity and message authentication are. 385 {{AD bit currently ratholed, update this when its fate is settled}} 387 There is one more step which a security-aware stub resolver can take 388 if, for whatever reason, it is not able to establish a useful trust 389 relationship with the recursive name servers which it uses: it can 390 perform its own signature validation, by setting the Checking 391 Disabled (CD) bit in its query messages. Upon taking this step, the 392 resolver is no longer really a stub resolver at all anymore (in the 393 terminology used in this document set, anyway), and is now a 394 security-aware resolver with somewhat limited functionality. 396 7. Zone Considerations 398 There are several differences between signed and unsigned zones. A 399 signed zone will contain additional security-related records (SIG, 400 KEY, DS and NXT records). SIG and NXT records may be generated by a 401 signing process prior to serving the zone. The SIG records that 402 accompany zone data have defined inception and expiration times, 403 which establish a validity period for the signatures and the zone 404 data the signatures cover. 406 7.1 TTL values vs. SIG validity period 408 It is important to note the distinction between an RRset's TTL value 409 and the signature validity period specified by the SIG RR covering 410 that RRset. DNSSEC does not change the definition or function of the 411 TTL value, which is intended to maintain database coherency in 412 caches. A caching resolver purges RRsets from its cache no later 413 than the end of the time period specified by the TTL fields of those 414 RRsets, regardless of whether or not the resolver is security-aware. 416 The inception and expiration fields in the SIG RR [13], on the other 417 hand, specify the time period during which the signature can be used 418 to validate the RRset that it covers. The signatures associated with 419 signed zone data are only valid for the time period specified by 420 these fields in the SIG RRs in question. TTL values cannot extend 421 the validity period of signed RRsets in a resolver's cache, but the 422 resolver may use the time remaining before expiration of the 423 signature validity period of a signed RRset as an upper bound for the 424 TTL of the signed RRset and its associated SIG RR in the resolver's 425 cache. 427 7.2 New Temporal Dependency Issues for Zones 429 Information in a signed zone has a temporal dependency which did not 430 exist in the original DNS protocol. A signed zone requires regular 431 maintenance to ensure that each RRset in the zone has a current valid 432 SIG RR. The signature validity period of a SIG RR is a interval 433 during which the signature for one particular signed RRset can be 434 considered valid, and the signatures of different RRsets in a zone 435 may expire at different times. Re-signing one or more RRsets in a 436 zone will change one or more SIG RRs, which in turn will require 437 incrementing the zone's SOA serial number to indicate that a zone 438 change has occurred and re-signing the SOA RRset itself. Thus, re- 439 signing any RRset in a zone may also trigger DNS NOTIFY messages and 440 zone transfers operations. 442 8. Name Server Considerations 444 A security-aware name server should include the appropriate DNSSEC 445 records (SIG, KEY, DS and NXT) in all responses to queries from 446 resolvers which have signaled their willingness to receive such 447 records via use of the DO bit in the EDNS header, subject to message 448 size limitations. For this reason a security-aware name server must 449 support the EDNS mechanism size extension, since otherwise inclusion 450 of DNSSEC RRs could easily cause UDP message truncation and fallback 451 to TCP. 453 If possible, the private half of each DNSSEC key pair should be kept 454 offline, but this will not be possible for a zone for which DNS 455 dynamic update has been enabled. In the dynamic update case, the 456 primary master server for the zone will have to re-sign the zone when 457 updated, so the private half of the zone signing key will have to be 458 kept online. This is an example of a situation where the ability to 459 separate the zone's KEY RRset into zone signing key(s) and key 460 signing key(s) may be useful, since the key singing key(s) in such a 461 case can still be kept offline. 463 DNSSEC, by itself, is not enough to protect the integrity of an 464 entire zone during zone transfer operations, since even a signed zone 465 contains some unsigned data, so zone maintenance operations will 466 require some additional mechanisms (most likely some form of channel 467 security, such as TSIG, SIG(0), or IPsec). 469 9. DNS Security Document Family 471 The DNSSEC set of documents can be partitioned into five main groups 472 as depicted in Figure 1. All these documents are in turn under the 473 larger umbrella of the DNS base protocol documents described in [18]. 475 9.1 DNS Security Document Roadmap 477 --------------------------------------------------------------------- 479 +----------------------------------+ 480 | Base DNS Protocol Documents | 481 | [RFC1035, RFC2181, et sequentia] | 482 +----------------------------------+ 483 | 484 | 485 +-----------+ +----------+ 486 | DNSSEC | | New | 487 | Protocol |--------->| Security | 488 | Documents | | Uses | 489 +-----------+ +----------+ 490 | 491 | 492 +---------------- - - - - - - -+ 493 | . 494 | . 495 +------------------+ . 496 | Digital | +------------------+ 497 | Signature | | Transaction | 498 | Algorithm | | Authentication | 499 | Implementations | | Implementations | 500 +------------------+ +------------------+ 502 Figure 1: DNSSEC Document Roadmap 504 --------------------------------------------------------------------- 506 9.2 Categories of DNS Security Documents 508 The "DNSSEC protocol document set" refers to the three documents 509 which form the core of the DNS security extensions: 511 1. DNS Security Introduction and Requirements (this document) 513 2. Resource Records for DNS Security Extensions [13] 514 3. Protocol Modifications for the DNS Security Extensions [14] 516 The "Digital Signature Algorithm Implementations" document set refers 517 to the group of documents that describe how specific digital 518 signature algorithms should be implemented to fit the DNSSEC resource 519 record format. Each of these documents deals with a specific digital 520 signature algorithm. 522 The "Transaction Authentication Implementations" document set refers 523 to the group of documents that deal with DNS message authentication, 524 including secret key establishment and verification. While not 525 strictly part of the DNSSEC specification as defined in this set of 526 documents, this group is noted to show its relationship to DNSSEC. 528 The final document set, "New Security Uses", refers to documents that 529 seek to use proposed DNS Security extensions for other security 530 related purposes. DNSSEC does not provide any direct security for 531 these new uses, but may be used to support them. Documents that fall 532 in this category include the use of DNS in the storage and 533 distribution of certificates [15] and individual user public keys 534 (PGP, e-mail, and so forth) [17]. 536 10. IANA Considerations 538 This document introduces no new IANA considerations. 540 11. Security Considerations 542 This document introduces the DNS security extensions and describes 543 the document set that contains the new security records and DNS 544 protocol modifications. This document discusses the capabilities and 545 limitations of these extensions. The extensions provide data origin 546 authentication and data integrity using digital signatures over 547 resource record sets. 549 In order for a security-aware resolver to validate a DNS response, 550 all of the intermediate zones must be signed, and all of the 551 intermediate name servers must be security-aware, as defined in this 552 document set. A security-aware resolver cannot verify responses 553 originating from an unsigned zone, from a zone not served by a 554 security-aware name server, or for any DNS data which the resolver is 555 only able to obtain through a recursive name server which is not 556 security-aware. If there is a break in the authentication chain such 557 that a security-aware resolver cannot obtain and validate the 558 authentication keys it needs, then the security-aware resolver cannot 559 validate the affected DNS data. 561 This document briefly discusses other methods of adding security to a 562 DNS query, such as using a channel secured by IPsec or using a DNS 563 transaction authentication mechanism, but transaction security is not 564 part of DNSSEC per se. 566 A security-aware stub resolver, by definition, does not perform 567 DNSSEC signature validation on its own, and thus is vulnerable both 568 to attacks on (and by) the security-aware recursive name servers 569 which perform these checks on its behalf and also to attacks on its 570 communication with those security-aware recursive name servers. 571 Security-aware stub resolvers should use some form of channel 572 security to defend against the latter threat. The only known defense 573 against the former threat would be for the security-aware stub 574 resolver to perform its own signature validation, at which point, 575 again by definition, it would no longer be a security-aware stub 576 resolver. 578 DNSSEC does not protect against denial of service attacks. DNSSEC 579 makes DNS vulnerable to a new class of denial of service attacks 580 based on cryptographic operations against security-aware resolvers 581 and security-aware name servers, since an attacker can attempt to use 582 DNSSEC mechanisms to consume a victim's resources. This class of 583 attacks takes at least two forms. An attacker may be able to consume 584 resources in a security-aware resolver's signature validation code by 585 tampering with SIG RRs in response messages or by constructing 586 needlessly complex signature chains. An attacker may also be able to 587 consume resources in a security-aware name server which supports DNS 588 dynamic update, by sending a stream of update messages that force the 589 security-aware name server to re-sign some RRsets in the zone more 590 frequently than would otherwise be necessary. 592 DNSSEC add the ability for a hostile party to enumerate all the names 593 in a zone by following the NXT chain. NXT RRs assert which names do 594 not exist in a zone by linking from existing name to existing name 595 along a canonical ordering of all the names within a zone. Thus, an 596 attacker can query these NXT RRs in sequence to obtain all the names 597 in a zone. While not an attack on the DNS itself, this could allow 598 an attacker to map network hosts or other resources by enumerating 599 the contents of a zone. 601 DNSSEC does not provide confidentiality, due to a deliberate design 602 choice. 604 DNSSEC does not protect against tampering with unsigned zone data. 605 Non-authoritative data at zone cuts (glue and NS RRs in the parent 606 zone) are not signed. Thus, while DNSSEC can provide data origin 607 authentication and data integrity for RRsets, it cannot do so for 608 zones, and other mechanisms must be used to protect zone transfer 609 operations. 611 12. Acknowledgements 613 This document was created from the input and ideas of several members 614 of the DNS Extensions Working Group. The authors would like to 615 acknowledge (in alphabetical order) the following people for their 616 contributions and comments on this document: 618 Derek Atkins 619 Donald Eastlake 620 Miek Gieben 621 Olafur Gudmundsson 622 Olaf Kolkman 623 Ed Lewis 624 Ted Lindgreen 625 Bill Manning 626 Brian Wellington 628 Normative References 630 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 631 13, RFC 1034, November 1987. 633 [2] Mockapetris, P., "Domain names - implementation and 634 specification", STD 13, RFC 1035, November 1987. 636 [3] Eastlake, D., "Domain Name System Security Extensions", RFC 637 2535, March 1999. 639 [4] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 640 August 1999. 642 [5] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 643 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 644 2845, May 2000. 646 [6] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 647 2930, September 2000. 649 [7] Eastlake, D., "DNS Request and Transaction Signatures ( 650 SIG(0)s)", RFC 2931, September 2000. 652 [8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, 653 December 2001. 655 [9] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 656 message size requirements", RFC 3226, December 2001. 658 [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 659 Record (RR)", RFC 3445, December 2002. 661 [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name 662 System", draft-ietf-dnsext-dns-threats-02 (work in progress), 663 February 2002. 665 [12] Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK) 666 Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in 667 progress), December 2002. 669 [13] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource 670 Records for DNS Security Extensions", draft-ietf-dnsext-dnssec- 671 records-02 (work in progress), November 2002. 673 [14] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol 674 Modifications for the DNS Security Extensions", draft-ietf- 675 dnsext-dnssec-protocol-00 (work in progress), October 2002. 677 Informative References 679 [15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 680 Domain Name System (DNS)", RFC 2538, March 1999. 682 [16] Wellington, B., "Secure Domain Name System (DNS) Dynamic 683 Update", RFC 3007, November 2000. 685 [17] Schlyter, J., "Storing application public keys in the DNS", 686 draft-schlyter-appkey-02 (work in progress), February 2002. 688 [18] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext- 689 dnssec-roadmap-06 (work in progress), November 2001. 691 Authors' Addresses 693 Roy Arends 694 Telematica Instituut 695 Drienerlolaan 5 696 7522 NB Enschede 697 NL 699 EMail: roy.arends@telin.nl 701 Rob Austein 702 Internet Software Consortium 703 40 Gavin Circle 704 Reading, MA 01867 705 USA 707 EMail: sra@isc.org 709 Matt Larson 710 VeriSign, Inc. 711 21345 Ridgetop Circle 712 Dulles, VA 20166-6503 713 USA 715 EMail: mlarson@verisign.com 716 Dan Massey 717 USC Information Sciences Institute 718 3811 N. Fairfax Drive 719 Arlington, VA 22203 720 USA 722 EMail: masseyd@isi.edu 724 Scott Rose 725 National Institute for Standards and Technology 726 100 Bureau Drive 727 Gaithersburg, MD 20899-8920 728 USA 730 EMail: scott.rose@nist.gov 732 Full Copyright Statement 734 Copyright (C) The Internet Society (2003). All Rights Reserved. 736 This document and translations of it may be copied and furnished to 737 others, and derivative works that comment on or otherwise explain it 738 or assist in its implementation may be prepared, copied, published 739 and distributed, in whole or in part, without restriction of any 740 kind, provided that the above copyright notice and this paragraph are 741 included on all such copies and derivative works. However, this 742 document itself may not be modified in any way, such as by removing 743 the copyright notice or references to the Internet Society or other 744 Internet organizations, except as needed for the purpose of 745 developing Internet standards in which case the procedures for 746 copyrights defined in the Internet Standards process must be 747 followed, or as required to translate it into languages other than 748 English. 750 The limited permissions granted above are perpetual and will not be 751 revoked by the Internet Society or its successors or assigns. 753 This document and the information contained herein is provided on an 754 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 755 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 756 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 757 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 758 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 760 Acknowledgement 762 Funding for the RFC Editor function is currently provided by the 763 Internet Society.