idnits 2.17.1 draft-ietf-dnsext-dnssec-intro-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 923. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 939), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (July 15, 2004) is 7225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-06 == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-08 ** 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) -- Obsolete informational reference (is this intentional?): RFC 2538 (Obsoleted by RFC 4398) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3008 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3090 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3655 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3757 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 15 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: January 13, 2005 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 July 15, 2004 14 DNS Security Introduction and Requirements 15 draft-ietf-dnsext-dnssec-intro-11 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 and any of which I become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 13, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract 48 The Domain Name System Security Extensions (DNSSEC) add data origin 49 authentication and data integrity to the Domain Name System. This 50 document introduces these extensions, and describes their 51 capabilities and limitations. This document also discusses the 52 services that the DNS security extensions do and do not provide. 53 Last, this document describes the interrelationships between the 54 group of documents that collectively describe DNSSEC. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 60 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 61 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 62 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 63 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 64 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 65 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 66 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 67 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 69 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 70 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 71 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 73 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 74 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 77 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 79 Intellectual Property and Copyright Statements . . . . . . . . 26 81 1. Introduction 83 This document introduces the Domain Name System Security Extensions 84 (DNSSEC). This document and its two companion documents 85 ([I-D.ietf-dnsext-dnssec-records] and 86 [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the 87 security extensions defined in RFC 2535 [RFC2535] and its 88 predecessors. These security extensions consist of a set of new 89 resource record types and modifications to the existing DNS protocol 90 [RFC1035]. The new records and protocol modifications are not fully 91 described in this document, but are described in a family of 92 documents outlined in Section 10. Section 3 and Section 4 describe 93 the capabilities and limitations of the security extensions in 94 greater detail. Section 5 discusses the scope of the document set. 95 Section 6, Section 7, Section 8, and Section 9 discuss the effect 96 that these security extensions will have on resolvers, stub 97 resolvers, zones and name servers. 99 This document and its two companions update and obsolete RFCs 2535 100 [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 101 [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress 102 [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but 103 does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 104 [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts 105 of 3226 [RFC3226] (dealing with DNSSEC). 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 RRsets forms a chain of signed data, with each link in the chain 121 vouching for the next. A DNSKEY RR is used to verify the 122 signature covering a DS RR and allows the DS RR to be 123 authenticated. The DS RR contains a hash of another DNSKEY RR and 124 this new DNSKEY RR is authenticated by matching the hash in the DS 125 RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset 126 and, in turn, some DNSKEY RR in this set may be used to 127 authenticate another DS RR and so forth until the chain finally 128 ends with a DNSKEY RR whose corresponding private key signs the 129 desired DNS data. For example, the root DNSKEY RRset can be used 130 to authenticate the DS RRset for "example." The "example." DS 131 RRset contains a hash that matches some "example." DNSKEY, and 132 this DNSKEY's corresponding private key signs the "example." 133 DNSKEY RRset. Private key counterparts of the "example." DNSKEY 134 RRset sign data records such as "www.example." as well as DS RRs 135 for delegations such as "subzone.example." 137 Authentication Key: A public key that a security-aware resolver has 138 verified and can therefore use to authenticate data. A 139 security-aware resolver can obtain authentication keys in three 140 ways. First, the resolver is generally configured to know about 141 at least one public key; this configured data is usually either 142 the public key itself or a hash of the public key as found in the 143 DS RR (see "trust anchor"). Second, the resolver may use an 144 authenticated public key to verify a DS RR and the DNSKEY RR to 145 which the DS RR refers. Third, the resolver may be able to 146 determine that a new public key has been signed by the private key 147 corresponding to another public key which the resolver has 148 verified. Note that the resolver must always be guided by local 149 policy when deciding whether to authenticate a new public key, 150 even if the local policy is simply to authenticate any new public 151 key for which the resolver is able verify the signature. 153 Delegation Point: Term used to describe the name at the parental side 154 of a zone cut. That is, the delegation point for "foo.example" 155 would be the foo.example node in the "example" zone (as opposed to 156 the zone apex of the "foo.example" zone). 158 Island of Security: Term used to describe a signed, delegated zone 159 that does not have an authentication chain from its delegating 160 parent. That is, there is no DS RR containing a hash of a DNSKEY 161 RR for the island in its delegating parent zone (see 162 [I-D.ietf-dnsext-dnssec-records]). An island of security is 163 served by security-aware name servers and may provide 164 authentication chains to any delegated child zones. Responses 165 from an island of security or its descendents can only be 166 authenticated if its authentication keys can be authenticated by 167 some trusted means out of band from the DNS protocol. 169 Key Signing Key (KSK): An authentication key that corresponds to a 170 private key used to sign one or more other authentication keys for 171 a given zone. Typically, the private key corresponding to a key 172 signing key will sign a zone signing key, which in turn has a 173 corresponding private key which will sign other zone data. Local 174 policy may require the zone signing key to be changed frequently, 175 while the key signing key may have a longer validity period in 176 order to provide a more stable secure entry point into the zone. 177 Designating an authentication key as a key signing key is purely 178 an operational issue: DNSSEC validation does not distinguish 179 between key signing keys and other DNSSEC authentication keys, and 180 it is possible to use a single key as both a key signing key and a 181 zone signing key. Key signing keys are discussed in more detail 182 in [RFC3757]. Also see: zone signing key. 184 Non-Validating Security-Aware Stub Resolver: A security-aware stub 185 resolver which trusts one or more security-aware recursive name 186 servers to perform most of the tasks discussed in this document 187 set on its behalf. In particular, a non-validating 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. See also: security-aware stub resolver, validating 193 security-aware stub resolver. 195 Non-Validating Stub Resolver: A less tedious term for a 196 non-validating security-aware stub resolver. 198 Security-Aware Name Server: An entity acting in the role of a name 199 server (defined in section 2.4 of [RFC1034]) that understands the 200 DNS security extensions defined in this document set. In 201 particular, a security-aware name server is an entity which 202 receives DNS queries, sends DNS responses, supports the EDNS0 203 [RFC2671] message size extension and the DO bit [RFC3225], and 204 supports the RR types and message header bits defined in this 205 document set. 207 Security-Aware Recursive Name Server: An entity which acts in both 208 the security-aware name server and security-aware resolver roles. 209 A more cumbersome equivalent phrase would be "a security-aware 210 name server which offers recursive service". 212 Security-Aware Resolver: An entity acting in the role of a resolver 213 (defined in section 2.4 of [RFC1034]) which understands the DNS 214 security extensions defined in this document set. In particular, 215 a security-aware resolver is an entity which sends DNS queries, 216 receives DNS responses, supports the EDNS0 [RFC2671] message size 217 extension and the DO bit [RFC3225], and is capable of using the RR 218 types and message header bits defined in this document set to 219 provide DNSSEC services. 221 Security-Aware Stub Resolver: An entity acting in the role of a stub 222 resolver (defined in section 5.3.1 of [RFC1034]) which has enough 223 of an understanding the DNS security extensions defined in this 224 document set to provide additional services not available from a 225 security-oblivious stub resolver. Security-aware stub resolvers 226 may be either "validating" or "non-validating" depending on 227 whether the stub resolver attempts to verify DNSSEC signatures on 228 its own or trusts a friendly security-aware name server to do so. 229 See also: validating stub resolver, non-validating stub resolver. 231 Security-Oblivious : An that is not 232 "security-aware". 234 Signed Zone: A zone whose RRsets are signed and which contains 235 properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS 236 records. 238 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A 239 validating security-aware resolver uses this public key or hash as 240 a starting point for building the authentication chain to a signed 241 DNS response. In general, a validating resolver will need to 242 obtain the initial values of its trust anchors via some secure or 243 trusted means outside the DNS protocol. Presence of a trust 244 anchor also implies that the resolver should expect the zone to 245 which the trust anchor points to be signed. 247 Unsigned Zone: A zone that is not signed. 249 Validating Security-Aware Stub Resolver: A security-aware resolver 250 that sends queries in recursive mode but which performs signature 251 validation on its own rather than just blindly trusting an 252 upstream security-aware recursive name server. See also: 253 security-aware stub resolver, non-validating security-aware stub 254 resolver. 256 Validating Stub Resolver: A less tedious term for a validating 257 security-aware stub resolver. 259 Zone Signing Key (ZSK): An authentication key that corresponds to a 260 private key used to sign a zone. Typically a zone signing key 261 will be part of the same DNSKEY RRset as the key signing key whose 262 corresponding private key signs this DNSKEY RRset, but the zone 263 signing key is used for a slightly different purpose, and may 264 differ from the key signing key in other ways, such as validity 265 lifetime. Designating an authentication key as a zone signing key 266 is purely an operational issue: DNSSEC validation does not 267 distinguish between zone signing keys and other DNSSEC 268 authentication keys, and it is possible to use a single key as 269 both a key signing key and a zone signing key. See also: key 270 signing key. 272 3. Services Provided by DNS Security 274 The Domain Name System (DNS) security extensions provide origin 275 authentication and integrity assurance services for DNS data, 276 including mechanisms for authenticated denial of existence of DNS 277 data. These mechanisms are described below. 279 These mechanisms require changes to the DNS protocol. DNSSEC adds 280 four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two 281 new message header bits (CD and AD). In order to support the larger 282 DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also 283 requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support 284 for the DO bit [RFC3225], so that a security-aware resolver can 285 indicate in its queries that it wishes to receive DNSSEC RRs in 286 response messages. 288 These services protect against most of the threats to the Domain Name 289 System described in [I-D.ietf-dnsext-dns-threats]. 291 3.1 Data Origin Authentication and Data Integrity 293 DNSSEC provides authentication by associating cryptographically 294 generated digital signatures with DNS RRsets. These digital 295 signatures are stored in a new resource record, the RRSIG record. 296 Typically, there will be a single private key that signs a zone's 297 data, but multiple keys are possible: for example, there may be keys 298 for each of several different digital signature algorithms. If a 299 security-aware resolver reliably learns a zone's public key, it can 300 authenticate that zone's signed data. An important DNSSEC concept is 301 that the key that signs a zone's data is associated with the zone 302 itself and not with the zone's authoritative name servers (public 303 keys for DNS transaction authentication mechanisms may also appear in 304 zones, as described in [RFC2931], but DNSSEC itself is concerned with 305 object security of DNS data, not channel security of DNS 306 transactions. The keys associated with transaction security may be 307 stored in different RR types. See [RFC3755] for details.). 309 A security-aware resolver can learn a zone's public key either by 310 having a trust anchor configured into the resolver or by normal DNS 311 resolution. To allow the latter, public keys are stored in a new 312 type of resource record, the DNSKEY RR. Note that the private keys 313 used to sign zone data must be kept secure, and should be stored 314 offline when practical to do so. To discover a public key reliably 315 via DNS resolution, the target key itself needs to be signed by 316 either a configured authentication key or another key that has been 317 authenticated previously. Security-aware resolvers authenticate zone 318 information by forming an authentication chain from a newly learned 319 public key back to a previously known authentication public key, 320 which in turn either has been configured into the resolver or must 321 have been learned and verified previously. Therefore, the resolver 322 must be configured with at least one trust anchor. If the configured 323 key is a zone signing key, then it will authenticate the associated 324 zone; if the configured key is a key signing key, it will 325 authenticate a zone signing key. If the resolver has been configured 326 with the hash of a key rather than the key itself, the resolver may 327 need to obtain the key via a DNS query. To help security-aware 328 resolvers establish this authentication chain, security-aware name 329 servers attempt to send the signature(s) needed to authenticate a 330 zone's public key(s) in the DNS reply message along with the public 331 key itself, provided there is space available in the message. 333 The Delegation Signer (DS) RR type simplifies some of the 334 administrative tasks involved in signing delegations across 335 organizational boundaries. The DS RRset resides at a delegation 336 point in a parent zone and indicates the public key(s) corresponding 337 to the private key(s) used to self-sign the DNSKEY RRset at the 338 delegated child zone's apex. The administrator of the child zone, in 339 turn, uses the private key(s) corresponding to one or more of the 340 public keys in this DNSKEY RRset to sign the child zone's data. The 341 typical authentication chain is therefore 342 DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more 343 DS->DNSKEY subchains. DNSSEC permits more complex authentication 344 chains, such as additional layers of DNSKEY RRs signing other DNSKEY 345 RRs within a zone. 347 A security-aware resolver normally constructs this authentication 348 chain from the root of the DNS hierarchy down to the leaf zones based 349 on configured knowledge of the public key for the root. Local 350 policy, however, may also allow a security-aware resolver to use one 351 or more configured public keys (or hashes of public keys) other than 352 the root public key, or may not provide configured knowledge of the 353 root public key, or may prevent the resolver from using particular 354 public keys for arbitrary reasons even if those public keys are 355 properly signed with verifiable signatures. DNSSEC provides 356 mechanisms by which a security-aware resolver can determine whether 357 an RRset's signature is "valid" within the meaning of DNSSEC. In the 358 final analysis however, authenticating both DNS keys and data is a 359 matter of local policy, which may extend or even override the 360 protocol extensions defined in this document set. See Section 5 for 361 further discussion. 363 3.2 Authenticating Name and Type Non-Existence 365 The security mechanism described in Section 3.1 only provides a way 366 to sign existing RRsets in a zone. The problem of providing negative 367 responses with the same level of authentication and integrity 368 requires the use of another new resource record type, the NSEC 369 record. The NSEC record allows a security-aware resolver to 370 authenticate a negative reply for either name or type non-existence 371 via the same mechanisms used to authenticate other DNS replies. Use 372 of NSEC records requires a canonical representation and ordering for 373 domain names in zones. Chains of NSEC records explicitly describe 374 the gaps, or "empty space", between domain names in a zone, as well 375 as listing the types of RRsets present at existing names. Each NSEC 376 record is signed and authenticated using the mechanisms described in 377 Section 3.1. 379 4. Services Not Provided by DNS Security 381 DNS was originally designed with the assumptions that the DNS will 382 return the same answer to any given query regardless of who may have 383 issued the query, and that all data in the DNS is thus visible. 384 Accordingly, DNSSEC is not designed to provide confidentiality, 385 access control lists, or other means of differentiating between 386 inquirers. 388 DNSSEC provides no protection against denial of service attacks. 389 Security-aware resolvers and security-aware name servers are 390 vulnerable to an additional class of denial of service attacks based 391 on cryptographic operations. Please see Section 12 for details. 393 The DNS security extensions provide data and origin authentication 394 for DNS data. The mechanisms outlined above are not designed to 395 protect operations such as zone transfers and dynamic update 396 [RFC3007]. Message authentication schemes described in [RFC2845] and 397 [RFC2931] address security operations that pertain to these 398 transactions. 400 5. Scope of the DNSSEC Document Set and Last Hop Issues 402 The specification in this document set defines the behavior for zone 403 signers and security-aware name servers and resolvers in such a way 404 that the validating entities can unambiguously determine the state of 405 the data. 407 A validating resolver can determine these 4 states: 409 Secure: The validating resolver has a trust anchor, a chain of trust 410 and is able to verify all the signatures in the response. 412 Insecure: The validating resolver has a trust anchor, a chain of 413 trust, and, at some delegation point, signed proof of the 414 non-existence of a DS record. That indicates that subsequent 415 branches in the tree are provably insecure. A validating resolver 416 may have local policy to mark parts of the domain space as 417 insecure. 419 Bogus: The validating resolver has a trust anchor and there is a 420 secure delegation which is indicating that subsidiary data will be 421 signed, but the response fails to validate due to one or more 422 reasons: missing signatures, expired signatures, signatures with 423 unsupported algorithms, data missing which the relevant NSEC RR 424 says should be present, and so forth. 426 Indeterminate: There is no trust anchor which would indicate that a 427 specific portion of the tree is secure. This is the default 428 operation mode. 430 This specification only defines how security aware name servers can 431 signal non-validating stub resolvers that data was found to be bogus 432 (using RCODE=2, "Server Failure" -- see 433 [I-D.ietf-dnsext-dnssec-protocol]). 435 There is a mechanism for security aware name servers to signal 436 security-aware stub resolvers that data was found to be secure (using 437 the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). 439 This specification does not define a format for communicating why 440 responses were found to be bogus or marked as insecure. The current 441 signaling mechanism does not distinguish between indeterminate and 442 insecure. 444 A method for signaling advanced error codes and policy between a 445 security aware stub resolver and security aware recursive nameservers 446 is a topic for future work, as is the interface between a security 447 aware resolver and the applications that use it. Note, however, that 448 the lack of the specification of such communication does not prohibit 449 deployment of signed zones or the deployment of security aware 450 recursive name servers that prohibit propagation of bogus data to the 451 applications. 453 6. Resolver Considerations 455 A security-aware resolver needs to be able to perform cryptographic 456 functions necessary to verify digital signatures using at least the 457 mandatory-to-implement algorithm(s). Security-aware resolvers must 458 also be capable of forming an authentication chain from a newly 459 learned zone back to an authentication key, as described above. This 460 process might require additional queries to intermediate DNS zones to 461 obtain necessary DNSKEY, DS and RRSIG records. A security-aware 462 resolver should be configured with at least one trust anchor as the 463 starting point from which it will attempt to establish authentication 464 chains. 466 If a security-aware resolver is separated from the relevant 467 authoritative name servers by a recursive name server or by any sort 468 of device which acts as a proxy for DNS, and if the recursive name 469 server or proxy is not security-aware, the security-aware resolver 470 may not be capable of operating in a secure mode. For example, if a 471 security-aware resolver's packets are routed through a network 472 address translation device that includes a DNS proxy which is not 473 security-aware, the security-aware resolver may find it difficult or 474 impossible to obtain or validate signed DNS data. 476 If a security-aware resolver must rely on an unsigned zone or a name 477 server that is not security aware, the resolver may not be able to 478 validate DNS responses, and will need a local policy on whether to 479 accept unverified responses. 481 A security-aware resolver should take a signature's validation period 482 into consideration when determining the TTL of data in its cache, to 483 avoid caching signed data beyond the validity period of the 484 signature, but should also allow for the possibility that the 485 security-aware resolver's own clock is wrong. Thus, a security-aware 486 resolver which is part of a security-aware recursive name server will 487 need to pay careful attention to the DNSSEC "checking disabled" (CD) 488 bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid 489 blocking valid signatures from getting through to other 490 security-aware resolvers which are clients of this recursive name 491 server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure 492 recursive server handles queries with the CD bit set. 494 7. Stub Resolver Considerations 496 Although not strictly required to do so by the protocol, most DNS 497 queries originate from stub resolvers. Stub resolvers, by 498 definition, are minimal DNS resolvers which use recursive query mode 499 to offload most of the work of DNS resolution to a recursive name 500 server. Given the widespread use of stub resolvers, the DNSSEC 501 architecture has to take stub resolvers into account, but the 502 security features needed in a stub resolver differ in some respects 503 from those needed in a full security-aware resolver. 505 Even a security-oblivious stub resolver may get some benefit from 506 DNSSEC if the recursive name servers it uses are security-aware, but 507 for the stub resolver to place any real reliance on DNSSEC services, 508 the stub resolver must trust both the recursive name servers in 509 question and the communication channels between itself and those name 510 servers. The first of these issues is a local policy issue: in 511 essence, a security-oblivious stub resolver has no real choice but to 512 place itself at the mercy of the recursive name servers that it uses, 513 since it does not perform DNSSEC validity checks on its own. The 514 second issue requires some kind of channel security mechanism; proper 515 use of DNS transaction authentication mechanisms such as SIG(0) or 516 TSIG would suffice, as would appropriate use of IPsec, and particular 517 implementations may have other choices available, such as operating 518 system specific interprocess communication mechanisms. 519 Confidentiality is not needed for this channel, but data integrity 520 and message authentication are. 522 A security-aware stub resolver that does trust both its recursive 523 name servers and its communication channel to them may choose to 524 examine the setting of the AD bit in the message header of the 525 response messages it receives. The stub resolver can use this flag 526 bit as a hint to find out whether the recursive name server was able 527 to validate signatures for all of the data in the Answer and 528 Authority sections of the response. 530 There is one more step that a security-aware stub resolver can take 531 if, for whatever reason, it is not able to establish a useful trust 532 relationship with the recursive name servers which it uses: it can 533 perform its own signature validation, by setting the Checking 534 Disabled (CD) bit in its query messages. A validating stub resolver 535 is thus able to treat the DNSSEC signatures as a trust relationship 536 between the zone administrator and the stub resolver itself. 538 8. Zone Considerations 540 There are several differences between signed and unsigned zones. A 541 signed zone will contain additional security-related records (RRSIG, 542 DNSKEY, DS and NSEC records). RRSIG and NSEC records may be 543 generated by a signing process prior to serving the zone. The RRSIG 544 records that accompany zone data have defined inception and 545 expiration times, which establish a validity period for the 546 signatures and the zone data the signatures cover. 548 8.1 TTL values vs. RRSIG validity period 550 It is important to note the distinction between a RRset's TTL value 551 and the signature validity period specified by the RRSIG RR covering 552 that RRset. DNSSEC does not change the definition or function of the 553 TTL value, which is intended to maintain database coherency in 554 caches. A caching resolver purges RRsets from its cache no later 555 than the end of the time period specified by the TTL fields of those 556 RRsets, regardless of whether or not the resolver is security-aware. 558 The inception and expiration fields in the RRSIG RR 559 [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time 560 period during which the signature can be used to validate the covered 561 RRset. The signatures associated with signed zone data are only 562 valid for the time period specified by these fields in the RRSIG RRs 563 in question. TTL values cannot extend the validity period of signed 564 RRsets in a resolver's cache, but the resolver may use the time 565 remaining before expiration of the signature validity period of a 566 signed RRset as an upper bound for the TTL of the signed RRset and 567 its associated RRSIG RR in the resolver's cache. 569 8.2 New Temporal Dependency Issues for Zones 571 Information in a signed zone has a temporal dependency which did not 572 exist in the original DNS protocol. A signed zone requires regular 573 maintenance to ensure that each RRset in the zone has a current valid 574 RRSIG RR. The signature validity period of an RRSIG RR is an 575 interval during which the signature for one particular signed RRset 576 can be considered valid, and the signatures of different RRsets in a 577 zone may expire at different times. Re-signing one or more RRsets in 578 a zone will change one or more RRSIG RRs, which in turn will require 579 incrementing the zone's SOA serial number to indicate that a zone 580 change has occurred and re-signing the SOA RRset itself. Thus, 581 re-signing any RRset in a zone may also trigger DNS NOTIFY messages 582 and zone transfers operations. 584 9. Name Server Considerations 586 A security-aware name server should include the appropriate DNSSEC 587 records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from 588 resolvers which have signaled their willingness to receive such 589 records via use of the DO bit in the EDNS header, subject to message 590 size limitations. Since inclusion of these DNSSEC RRs could easily 591 cause UDP message truncation and fallback to TCP, a security-aware 592 name server must also support the EDNS "sender's UDP payload" 593 mechanism. 595 If possible, the private half of each DNSSEC key pair should be kept 596 offline, but this will not be possible for a zone for which DNS 597 dynamic update has been enabled. In the dynamic update case, the 598 primary master server for the zone will have to re-sign the zone when 599 updated, so the private key corresponding to the zone signing key 600 will have to be kept online. This is an example of a situation where 601 the ability to separate the zone's DNSKEY RRset into zone signing 602 key(s) and key signing key(s) may be useful, since the key signing 603 key(s) in such a case can still be kept offline and may have a longer 604 useful lifetime than the zone signing key(s). 606 DNSSEC, by itself, is not enough to protect the integrity of an 607 entire zone during zone transfer operations, since even a signed zone 608 contains some unsigned, nonauthoritative data if the zone has any 609 children. Therefore, zone maintenance operations will require some 610 additional mechanisms (most likely some form of channel security, 611 such as TSIG, SIG(0), or IPsec). 613 10. DNS Security Document Family 615 The DNSSEC document set can be partitioned into several main groups, 616 under the larger umbrella of the DNS base protocol documents. 618 The "DNSSEC protocol document set" refers to the three documents 619 which form the core of the DNS security extensions: 620 1. DNS Security Introduction and Requirements (this document) 621 2. Resource Records for DNS Security Extensions 622 [I-D.ietf-dnsext-dnssec-records] 623 3. Protocol Modifications for the DNS Security Extensions 624 [I-D.ietf-dnsext-dnssec-protocol] 626 Additionally, any document that would add to, or change the core DNS 627 Security extensions would fall into this category. This includes any 628 future work on the communication between security-aware stub 629 resolvers and upstream security-aware recursive name servers. 631 The "Digital Signature Algorithm Specification" document set refers 632 to the group of documents that describe how specific digital 633 signature algorithms should be implemented to fit the DNSSEC resource 634 record format. Each document in this set deals with a specific 635 digital signature algorithm. 637 The "Transaction Authentication Protocol" document set refers to the 638 group of documents that deal with DNS message authentication, 639 including secret key establishment and verification. While not 640 strictly part of the DNSSEC specification as defined in this set of 641 documents, this group is noted because of its relationship to DNSSEC. 643 The final document set, "New Security Uses", refers to documents that 644 seek to use proposed DNS Security extensions for other security 645 related purposes. DNSSEC does not provide any direct security for 646 these new uses, but may be used to support them. Documents that fall 647 in this category include the use of DNS in the storage and 648 distribution of certificates [RFC2538]. 650 11. IANA Considerations 652 This overview document introduces no new IANA considerations. Please 653 see [I-D.ietf-dnsext-dnssec-records] for a complete review of the 654 IANA considerations introduced by DNSSEC. 656 12. Security Considerations 658 This document introduces the DNS security extensions and describes 659 the document set that contains the new security records and DNS 660 protocol modifications. The extensions provide data origin 661 authentication and data integrity using digital signatures over 662 resource record sets.This document discusses the capabilities and 663 limitations of these extensions. 665 In order for a security-aware resolver to validate a DNS response, 666 all zones along the path from the trusted starting point to the zone 667 containing the response zones must be signed, and all name servers 668 and resolvers involved in the resolution process must be 669 security-aware, as defined in this document set. A security-aware 670 resolver cannot verify responses originating from an unsigned zone, 671 from a zone not served by a security-aware name server, or for any 672 DNS data which the resolver is only able to obtain through a 673 recursive name server which is not security-aware. If there is a 674 break in the authentication chain such that a security-aware resolver 675 cannot obtain and validate the authentication keys it needs, then the 676 security-aware resolver cannot validate the affected DNS data. 678 This document briefly discusses other methods of adding security to a 679 DNS query, such as using a channel secured by IPsec or using a DNS 680 transaction authentication mechanism, but transaction security is not 681 part of DNSSEC per se. 683 A non-validating security-aware stub resolver, by definition, does 684 not perform DNSSEC signature validation on its own, and thus is 685 vulnerable both to attacks on (and by) the security-aware recursive 686 name servers which perform these checks on its behalf and also to 687 attacks on its communication with those security-aware recursive name 688 servers. Non-validating security-aware stub resolvers should use 689 some form of channel security to defend against the latter threat. 690 The only known defense against the former threat would be for the 691 security-aware stub resolver to perform its own signature validation, 692 at which point, again by definition, it would no longer be a 693 non-validating security-aware stub resolver. 695 DNSSEC does not protect against denial of service attacks. DNSSEC 696 makes DNS vulnerable to a new class of denial of service attacks 697 based on cryptographic operations against security-aware resolvers 698 and security-aware name servers, since an attacker can attempt to use 699 DNSSEC mechanisms to consume a victim's resources. This class of 700 attacks takes at least two forms. An attacker may be able to consume 701 resources in a security-aware resolver's signature validation code by 702 tampering with RRSIG RRs in response messages or by constructing 703 needlessly complex signature chains. An attacker may also be able to 704 consume resources in a security-aware name server which supports DNS 705 dynamic update, by sending a stream of update messages that force the 706 security-aware name server to re-sign some RRsets in the zone more 707 frequently than would otherwise be necessary. 709 DNSSEC does not provide confidentiality, due to a deliberate design 710 choice. 712 DNSSEC introduces the ability for a hostile party to enumerate all 713 the names in a zone by following the NSEC chain. NSEC RRs assert 714 which names do not exist in a zone by linking from existing name to 715 existing name along a canonical ordering of all the names within a 716 zone. Thus, an attacker can query these NSEC RRs in sequence to 717 obtain all the names in a zone. While not an attack on the DNS 718 itself, this could allow an attacker to map network hosts or other 719 resources by enumerating the contents of a zone. 721 DNSSEC introduces significant additional complexity to the DNS, and 722 thus introduces many new opportunities for implementation bugs and 723 misconfigured zones. In particular, enabling DNSSEC signature 724 validation in a resolver may cause entire legitimate zones to become 725 effectively unreachable due to DNSSEC configuration errors or bugs. 727 DNSSEC does not protect against tampering with unsigned zone data. 728 Non-authoritative data at zone cuts (glue and NS RRs in the parent 729 zone) are not signed. This does not pose a problem when validating 730 the authentication chain, but does mean that the non-authoritative 731 data itself is vulnerable to tampering during zone transfer 732 operations. Thus, while DNSSEC can provide data origin 733 authentication and data integrity for RRsets, it cannot do so for 734 zones, and other mechanisms must be used to protect zone transfer 735 operations. 737 Please see [I-D.ietf-dnsext-dnssec-records] and 738 [I-D.ietf-dnsext-dnssec-protocol] for additional security 739 considerations. 741 13. Acknowledgements 743 This document was created from the input and ideas of the members of 744 the DNS Extensions Working Group. While explicitly listing everyone 745 who has contributed during the decade during which DNSSEC has been 746 under development would be an impossible task, the editors would 747 particularly like to thank the following people for their 748 contributions to and comments on this document set: Jaap Akkerhuis, 749 Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, 750 David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald 751 Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, 752 Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip 753 Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, 754 Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon 755 Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, 756 Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, 757 Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ 758 Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, 759 Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob 760 Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and 761 Suzanne Woolf. 763 No doubt the above list is incomplete. We apologize to anyone we 764 left out. 766 14. References 768 14.1 Normative References 770 [I-D.ietf-dnsext-dnssec-protocol] 771 Arends, R., Austein, R., Larson, M., Massey, D. and S. 772 Rose, "Protocol Modifications for the DNS Security 773 Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in 774 progress), May 2004. 776 [I-D.ietf-dnsext-dnssec-records] 777 Arends, R., Austein, R., Larson, M., Massey, D. and S. 778 Rose, "Resource Records for DNS Security Extensions", 779 draft-ietf-dnsext-dnssec-records-08 (work in progress), 780 May 2004. 782 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 783 STD 13, RFC 1034, November 1987. 785 [RFC1035] Mockapetris, P., "Domain names - implementation and 786 specification", STD 13, RFC 1035, November 1987. 788 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 789 RFC 2535, March 1999. 791 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 792 2671, August 1999. 794 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 795 3225, December 2001. 797 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 798 message size requirements", RFC 3226, December 2001. 800 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 801 Resource Record (RR)", RFC 3445, December 2002. 803 14.2 Informative References 805 [I-D.ietf-dnsext-dns-threats] 806 Atkins, D. and R. Austein, "Threat Analysis Of The Domain 807 Name System", draft-ietf-dnsext-dns-threats-07 (work in 808 progress), April 2004. 810 [I-D.ietf-dnsext-nsec-rdata] 811 Schlyter, J., "DNSSEC NSEC RDATA Format", 812 draft-ietf-dnsext-nsec-rdata-06 (work in progress), May 813 2004. 815 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 816 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 817 April 1997. 819 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 820 Specification", RFC 2181, July 1997. 822 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 823 NCACHE)", RFC 2308, March 1998. 825 [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in 826 the Domain Name System (DNS)", RFC 2538, March 1999. 828 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. 829 Wellington, "Secret Key Transaction Authentication for DNS 830 (TSIG)", RFC 2845, May 2000. 832 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 833 SIG(0)s)", RFC 2931, September 2000. 835 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 836 Update", RFC 3007, November 2000. 838 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) 839 Signing Authority", RFC 3008, November 2000. 841 [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone 842 Status", RFC 3090, March 2001. 844 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 845 (RR) Types", RFC 3597, September 2003. 847 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 848 Authenticated Data (AD) bit", RFC 3655, November 2003. 850 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 851 (RR)", RFC 3658, December 2003. 853 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 854 Signer", RFC 3755, April 2004. 856 [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure 857 Entry Point Flag", RFC 3757, April 2004. 859 Authors' Addresses 861 Roy Arends 862 Telematica Instituut 863 Drienerlolaan 5 864 7522 NB Enschede 865 NL 867 EMail: roy.arends@telin.nl 869 Rob Austein 870 Internet Systems Consortium 871 950 Charter Street 872 Redwood City, CA 94063 873 USA 875 EMail: sra@isc.org 877 Matt Larson 878 VeriSign, Inc. 879 21345 Ridgetop Circle 880 Dulles, VA 20166-6503 881 USA 883 EMail: mlarson@verisign.com 885 Dan Massey 886 USC Information Sciences Institute 887 3811 N. Fairfax Drive 888 Arlington, VA 22203 889 USA 891 EMail: masseyd@isi.edu 893 Scott Rose 894 National Institute for Standards and Technology 895 100 Bureau Drive 896 Gaithersburg, MD 20899-8920 897 USA 899 EMail: scott.rose@nist.gov 901 Intellectual Property Statement 903 The IETF takes no position regarding the validity or scope of any 904 Intellectual Property Rights or other rights that might be claimed to 905 pertain to the implementation or use of the technology described in 906 this document or the extent to which any license under such rights 907 might or might not be available; nor does it represent that it has 908 made any independent effort to identify any such rights. Information 909 on the procedures with respect to rights in RFC documents can be 910 found in BCP 78 and BCP 79. 912 Copies of IPR disclosures made to the IETF Secretariat and any 913 assurances of licenses to be made available, or the result of an 914 attempt made to obtain a general license or permission for the use of 915 such proprietary rights by implementers or users of this 916 specification can be obtained from the IETF on-line IPR repository at 917 http://www.ietf.org/ipr. 919 The IETF invites any interested party to bring to its attention any 920 copyrights, patents or patent applications, or other proprietary 921 rights that may cover technology that may be required to implement 922 this standard. Please address the information to the IETF at 923 ietf-ipr@ietf.org. 925 Disclaimer of Validity 927 This document and the information contained herein are provided on an 928 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 929 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 930 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 931 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 932 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 933 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 935 Copyright Statement 937 Copyright (C) The Internet Society (2004). This document is subject 938 to the rights, licenses and restrictions contained in BCP 78, and 939 except as set forth therein, the authors retain all their rights. 941 Acknowledgment 943 Funding for the RFC Editor function is currently provided by the 944 Internet Society.