1 Network Working Group R. Arends
2 Request for Comments: 4033 Telematica Instituut
3 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
4 3755, 3757, 3845 ISC
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
RFC6014 says that it updates RFC 4033, but nothing in the text of RFC 6014 says why.
5 Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
6 3007, 3597, 3226 VeriSign
7 Category: Standards Track D. Massey
8 Colorado State University
9 S. Rose
10 NIST
11 March 2005
12
13
14 DNS Security Introduction and Requirements
15
16 Status of This Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24 Copyright Notice
25
26 Copyright (C) The Internet Society (2005).
27
28 Abstract
29
30 The Domain Name System Security Extensions (DNSSEC) add data origin
31 authentication and data integrity to the Domain Name System. This
32 document introduces these extensions and describes their capabilities
33 and limitations. This document also discusses the services that the
34 DNS security extensions do and do not provide. Last, this document
35 describes the interrelationships between the documents that
36 collectively describe DNSSEC.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Arends, et al. Standards Track [Page 1]
53 RFC 4033 DNS Security Introduction and Requirements March 2005
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3
60 3. Services Provided by DNS Security . . . . . . . . . . . . . 7
61 3.1. Data Origin Authentication and Data Integrity . . . . 7
62 3.2. Authenticating Name and Type Non-Existence . . . . . . 9
63 4. Services Not Provided by DNS Security . . . . . . . . . . . 9
64 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9
65 6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10
66 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11
67 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12
68 8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13
69 8.2. New Temporal Dependency Issues for Zones . . . . . . . 13
70 9. Name Server Considerations . . . . . . . . . . . . . . . . . 13
71 10. DNS Security Document Family . . . . . . . . . . . . . . . . 14
72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
73 12. Security Considerations . . . . . . . . . . . . . . . . . . 15
74 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
76 14.1. Normative References . . . . . . . . . . . . . . . . . 17
77 14.2. Informative References . . . . . . . . . . . . . . . . 18
78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
79 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
80
81 1. Introduction
82
83 This document introduces the Domain Name System Security Extensions
84 (DNSSEC). This document and its two companion documents ([RFC4034]
85 and [RFC4035]) update, clarify, and refine the security extensions
86 defined in [RFC2535] and its predecessors. These security extensions
87 consist of a set of new resource record types and modifications to
88 the existing DNS protocol ([RFC1035]). The new records and protocol
89 modifications are not fully described in this document, but are
90 described in a family of documents outlined in Section 10. Sections
91 3 and 4 describe the capabilities and limitations of the security
92 extensions in greater detail. Section 5 discusses the scope of the
93 document set. Sections 6, 7, 8, and 9 discuss the effect that these
94 security extensions will have on resolvers, stub resolvers, zones,
95 and name servers.
96
97 This document and its two companions obsolete [RFC2535], [RFC3008],
98 [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
99 [RFC3845]. This document set also updates but does not obsolete
100 [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
101 [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
102 DNSSEC.
103
104
105
106
107 Arends, et al. Standards Track [Page 2]
108 RFC 4033 DNS Security Introduction and Requirements March 2005
109
110
111 The DNS security extensions provide origin authentication and
112 integrity protection for DNS data, as well as a means of public key
113 distribution. These extensions do not provide confidentiality.
114
115 2. Definitions of Important DNSSEC Terms
116
117 This section defines a number of terms used in this document set.
118 Because this is intended to be useful as a reference while reading
119 the rest of the document set, first-time readers may wish to skim
120 this section quickly, read the rest of this document, and then come
121 back to this section.
122
123 Authentication Chain: An alternating sequence of DNS public key
124 (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
125 signed data, with each link in the chain vouching for the next. A
126 DNSKEY RR is used to verify the signature covering a DS RR and
127 allows the DS RR to be authenticated. The DS RR contains a hash
128 of another DNSKEY RR and this new DNSKEY RR is authenticated by
129 matching the hash in the DS RR. This new DNSKEY RR in turn
130 authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
131 this set may be used to authenticate another DS RR, and so forth
132 until the chain finally ends with a DNSKEY RR whose corresponding
133 private key signs the desired DNS data. For example, the root
134 DNSKEY RRset can be used to authenticate the DS RRset for
135 "example." The "example." DS RRset contains a hash that matches
136 some "example." DNSKEY, and this DNSKEY's corresponding private
137 key signs the "example." DNSKEY RRset. Private key counterparts
138 of the "example." DNSKEY RRset sign data records such as
139 "www.example." and DS RRs for delegations such as
140 "subzone.example."
141
142 Authentication Key: A public key that a security-aware resolver has
143 verified and can therefore use to authenticate data. A
144 security-aware resolver can obtain authentication keys in three
145 ways. First, the resolver is generally configured to know about
146 at least one public key; this configured data is usually either
147 the public key itself or a hash of the public key as found in the
148 DS RR (see "trust anchor"). Second, the resolver may use an
149 authenticated public key to verify a DS RR and the DNSKEY RR to
150 which the DS RR refers. Third, the resolver may be able to
151 determine that a new public key has been signed by the private key
152 corresponding to another public key that the resolver has
153 verified. Note that the resolver must always be guided by local
154 policy when deciding whether to authenticate a new public key,
155 even if the local policy is simply to authenticate any new public
156 key for which the resolver is able verify the signature.
157
158
159
160
161
162 Arends, et al. Standards Track [Page 3]
163 RFC 4033 DNS Security Introduction and Requirements March 2005
164
165
166 Authoritative RRset: Within the context of a particular zone, an
167 RRset is "authoritative" if and only if the owner name of the
168 RRset lies within the subset of the name space that is at or below
169 the zone apex and at or above the cuts that separate the zone from
170 its children, if any. All RRsets at the zone apex are
171 authoritative, except for certain RRsets at this domain name that,
172 if present, belong to this zone's parent. These RRset could
173 include a DS RRset, the NSEC RRset referencing this DS RRset (the
174 "parental NSEC"), and RRSIG RRs associated with these RRsets, all
175 of which are authoritative in the parent zone. Similarly, if this
176 zone contains any delegation points, only the parental NSEC RRset,
177 DS RRsets, and any RRSIG RRs associated with these RRsets are
178 authoritative for this zone.
179
180 Delegation Point: Term used to describe the name at the parental side
181 of a zone cut. That is, the delegation point for "foo.example"
182 would be the foo.example node in the "example" zone (as opposed to
183 the zone apex of the "foo.example" zone). See also zone apex.
184
185 Island of Security: Term used to describe a signed, delegated zone
186 that does not have an authentication chain from its delegating
187 parent. That is, there is no DS RR containing a hash of a DNSKEY
188 RR for the island in its delegating parent zone (see [RFC4034]).
189 An island of security is served by security-aware name servers and
190 may provide authentication chains to any delegated child zones.
191 Responses from an island of security or its descendents can only
192 be authenticated if its authentication keys can be authenticated
193 by some trusted means out of band from the DNS protocol.
194
195 Key Signing Key (KSK): An authentication key that corresponds to a
196 private key used to sign one or more other authentication keys for
197 a given zone. Typically, the private key corresponding to a key
198 signing key will sign a zone signing key, which in turn has a
199 corresponding private key that will sign other zone data. Local
200 policy may require that the zone signing key be changed
201 frequently, while the key signing key may have a longer validity
202 period in order to provide a more stable secure entry point into
203 the zone. Designating an authentication key as a key signing key
204 is purely an operational issue: DNSSEC validation does not
205 distinguish between key signing keys and other DNSSEC
206 authentication keys, and it is possible to use a single key as
207 both a key signing key and a zone signing key. Key signing keys
208 are discussed in more detail in [RFC3757]. Also see zone signing
209 key.
210
211
212
213
214
215
216
217 Arends, et al. Standards Track [Page 4]
218 RFC 4033 DNS Security Introduction and Requirements March 2005
219
220
221 Non-Validating Security-Aware Stub Resolver: A security-aware stub
222 resolver that trusts one or more security-aware recursive name
223 servers to perform most of the tasks discussed in this document
224 set on its behalf. In particular, a non-validating security-aware
225 stub resolver is an entity that sends DNS queries, receives DNS
226 responses, and is capable of establishing an appropriately secured
227 channel to a security-aware recursive name server that will
228 provide these services on behalf of the security-aware stub
229 resolver. See also security-aware stub resolver, validating
230 security-aware stub resolver.
231
232 Non-Validating Stub Resolver: A less tedious term for a
233 non-validating security-aware stub resolver.
234
235 Security-Aware Name Server: An entity acting in the role of a name
236 server (defined in section 2.4 of [RFC1034]) that understands the
237 DNS security extensions defined in this document set. In
238 particular, a security-aware name server is an entity that
239 receives DNS queries, sends DNS responses, supports the EDNS0
240 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
241 supports the RR types and message header bits defined in this
242 document set.
243
244 Security-Aware Recursive Name Server: An entity that acts in both the
245 security-aware name server and security-aware resolver roles. A
246 more cumbersome but equivalent phrase would be "a security-aware
247 name server that offers recursive service".
248
249 Security-Aware Resolver: An entity acting in the role of a resolver
250 (defined in section 2.4 of [RFC1034]) that understands the DNS
251 security extensions defined in this document set. In particular,
252 a security-aware resolver is an entity that sends DNS queries,
253 receives DNS responses, supports the EDNS0 ([RFC2671]) message
254 size extension and the DO bit ([RFC3225]), and is capable of using
255 the RR types and message header bits defined in this document set
256 to provide DNSSEC services.
257
258 Security-Aware Stub Resolver: An entity acting in the role of a stub
259 resolver (defined in section 5.3.1 of [RFC1034]) that has enough
260 of an understanding the DNS security extensions defined in this
261 document set to provide additional services not available from a
262 security-oblivious stub resolver. Security-aware stub resolvers
263 may be either "validating" or "non-validating", depending on
264 whether the stub resolver attempts to verify DNSSEC signatures on
265 its own or trusts a friendly security-aware name server to do so.
266 See also validating stub resolver, non-validating stub resolver.
267
268
269
270
271
272 Arends, et al. Standards Track [Page 5]
273 RFC 4033 DNS Security Introduction and Requirements March 2005
274
275
276 Security-Oblivious <anything>: An <anything> that is not
277 "security-aware".
278
279 Signed Zone: A zone whose RRsets are signed and that contains
280 properly constructed DNSKEY, Resource Record Signature (RRSIG),
281 Next Secure (NSEC), and (optionally) DS records.
282
283 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A
284 validating security-aware resolver uses this public key or hash as
285 a starting point for building the authentication chain to a signed
286 DNS response. In general, a validating resolver will have to
287 obtain the initial values of its trust anchors via some secure or
288 trusted means outside the DNS protocol. Presence of a trust
289 anchor also implies that the resolver should expect the zone to
290 which the trust anchor points to be signed.
291
292 Unsigned Zone: A zone that is not signed.
293
294 Validating Security-Aware Stub Resolver: A security-aware resolver
295 that sends queries in recursive mode but that performs signature
296 validation on its own rather than just blindly trusting an
297 upstream security-aware recursive name server. See also
298 security-aware stub resolver, non-validating security-aware stub
299 resolver.
300
301 Validating Stub Resolver: A less tedious term for a validating
302 security-aware stub resolver.
303
304 Zone Apex: Term used to describe the name at the child's side of a
305 zone cut. See also delegation point.
306
307 Zone Signing Key (ZSK): An authentication key that corresponds to a
308 private key used to sign a zone. Typically, a zone signing key
309 will be part of the same DNSKEY RRset as the key signing key whose
310 corresponding private key signs this DNSKEY RRset, but the zone
311 signing key is used for a slightly different purpose and may
312 differ from the key signing key in other ways, such as validity
313 lifetime. Designating an authentication key as a zone signing key
314 is purely an operational issue; DNSSEC validation does not
315 distinguish between zone signing keys and other DNSSEC
316 authentication keys, and it is possible to use a single key as
317 both a key signing key and a zone signing key. See also key
318 signing key.
319
320
321
322
323
324
325
326
327 Arends, et al. Standards Track [Page 6]
328 RFC 4033 DNS Security Introduction and Requirements March 2005
329
330
331 3. Services Provided by DNS Security
332
333 The Domain Name System (DNS) security extensions provide origin
334 authentication and integrity assurance services for DNS data,
335 including mechanisms for authenticated denial of existence of DNS
336 data. These mechanisms are described below.
337
338 These mechanisms require changes to the DNS protocol. DNSSEC adds
339 four new resource record types: Resource Record Signature (RRSIG),
340 DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
341 (NSEC). It also adds two new message header bits: Checking Disabled
342 (CD) and Authenticated Data (AD). In order to support the larger DNS
343 message sizes that result from adding the DNSSEC RRs, DNSSEC also
344 requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support
345 for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
346 security-aware resolver can indicate in its queries that it wishes to
347 receive DNSSEC RRs in response messages.
348
349 These services protect against most of the threats to the Domain Name
350 System described in [RFC3833]. Please see Section 12 for a
351 discussion of the limitations of these extensions.
352
353 3.1. Data Origin Authentication and Data Integrity
354
355 DNSSEC provides authentication by associating cryptographically
356 generated digital signatures with DNS RRsets. These digital
357 signatures are stored in a new resource record, the RRSIG record.
358 Typically, there will be a single private key that signs a zone's
359 data, but multiple keys are possible. For example, there may be keys
360 for each of several different digital signature algorithms. If a
361 security-aware resolver reliably learns a zone's public key, it can
362 authenticate that zone's signed data. An important DNSSEC concept is
363 that the key that signs a zone's data is associated with the zone
364 itself and not with the zone's authoritative name servers. (Public
365 keys for DNS transaction authentication mechanisms may also appear in
366 zones, as described in [RFC2931], but DNSSEC itself is concerned with
367 object security of DNS data, not channel security of DNS
368 transactions. The keys associated with transaction security may be
369 stored in different RR types. See [RFC3755] for details.)
370
371 A security-aware resolver can learn a zone's public key either by
372 having a trust anchor configured into the resolver or by normal DNS
373 resolution. To allow the latter, public keys are stored in a new
374 type of resource record, the DNSKEY RR. Note that the private keys
375 used to sign zone data must be kept secure and should be stored
376 offline when practical. To discover a public key reliably via DNS
377 resolution, the target key itself has to be signed by either a
378 configured authentication key or another key that has been
379
380
381
382 Arends, et al. Standards Track [Page 7]
383 RFC 4033 DNS Security Introduction and Requirements March 2005
384
385
386 authenticated previously. Security-aware resolvers authenticate zone
387 information by forming an authentication chain from a newly learned
388 public key back to a previously known authentication public key,
389 which in turn either has been configured into the resolver or must
390 have been learned and verified previously. Therefore, the resolver
391 must be configured with at least one trust anchor.
392
393 If the configured trust anchor is a zone signing key, then it will
394 authenticate the associated zone; if the configured key is a key
395 signing key, it will authenticate a zone signing key. If the
396 configured trust anchor is the hash of a key rather than the key
397 itself, the resolver may have to obtain the key via a DNS query. To
398 help security-aware resolvers establish this authentication chain,
399 security-aware name servers attempt to send the signature(s) needed
400 to authenticate a zone's public key(s) in the DNS reply message along
401 with the public key itself, provided that there is space available in
402 the message.
403
404 The Delegation Signer (DS) RR type simplifies some of the
405 administrative tasks involved in signing delegations across
406 organizational boundaries. The DS RRset resides at a delegation
407 point in a parent zone and indicates the public key(s) corresponding
408 to the private key(s) used to self-sign the DNSKEY RRset at the
409 delegated child zone's apex. The administrator of the child zone, in
410 turn, uses the private key(s) corresponding to one or more of the
411 public keys in this DNSKEY RRset to sign the child zone's data. The
412 typical authentication chain is therefore
413 DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
414 DS->DNSKEY subchains. DNSSEC permits more complex authentication
415 chains, such as additional layers of DNSKEY RRs signing other DNSKEY
416 RRs within a zone.
417
418 A security-aware resolver normally constructs this authentication
419 chain from the root of the DNS hierarchy down to the leaf zones based
420 on configured knowledge of the public key for the root. Local
421 policy, however, may also allow a security-aware resolver to use one
422 or more configured public keys (or hashes of public keys) other than
423 the root public key, may not provide configured knowledge of the root
424 public key, or may prevent the resolver from using particular public
425 keys for arbitrary reasons, even if those public keys are properly
426 signed with verifiable signatures. DNSSEC provides mechanisms by
427 which a security-aware resolver can determine whether an RRset's
428 signature is "valid" within the meaning of DNSSEC. In the final
429 analysis, however, authenticating both DNS keys and data is a matter
430 of local policy, which may extend or even override the protocol
431 extensions defined in this document set. See Section 5 for further
432 discussion.
433
434
435
436
437 Arends, et al. Standards Track [Page 8]
438 RFC 4033 DNS Security Introduction and Requirements March 2005
439
440
441 3.2. Authenticating Name and Type Non-Existence
442
443 The security mechanism described in Section 3.1 only provides a way
444 to sign existing RRsets in a zone. The problem of providing negative
445 responses with the same level of authentication and integrity
446 requires the use of another new resource record type, the NSEC
447 record. The NSEC record allows a security-aware resolver to
448 authenticate a negative reply for either name or type non-existence
449 with the same mechanisms used to authenticate other DNS replies. Use
450 of NSEC records requires a canonical representation and ordering for
451 domain names in zones. Chains of NSEC records explicitly describe
452 the gaps, or "empty space", between domain names in a zone and list
453 the types of RRsets present at existing names. Each NSEC record is
454 signed and authenticated using the mechanisms described in Section
455 3.1.
456
457 4. Services Not Provided by DNS Security
458
459 DNS was originally designed with the assumptions that the DNS will
460 return the same answer to any given query regardless of who may have
461 issued the query, and that all data in the DNS is thus visible.
462 Accordingly, DNSSEC is not designed to provide confidentiality,
463 access control lists, or other means of differentiating between
464 inquirers.
465
466 DNSSEC provides no protection against denial of service attacks.
467 Security-aware resolvers and security-aware name servers are
468 vulnerable to an additional class of denial of service attacks based
469 on cryptographic operations. Please see Section 12 for details.
470
471 The DNS security extensions provide data and origin authentication
472 for DNS data. The mechanisms outlined above are not designed to
473 protect operations such as zone transfers and dynamic update
474 ([RFC2136], [RFC3007]). Message authentication schemes described in
475 [RFC2845] and [RFC2931] address security operations that pertain to
476 these transactions.
477
478 5. Scope of the DNSSEC Document Set and Last Hop Issues
479
480 The specification in this document set defines the behavior for zone
481 signers and security-aware name servers and resolvers in such a way
482 that the validating entities can unambiguously determine the state of
483 the data.
484
485 A validating resolver can determine the following 4 states:
486
487 Secure: The validating resolver has a trust anchor, has a chain of
488 trust, and is able to verify all the signatures in the response.
489
490
491
492 Arends, et al. Standards Track [Page 9]
493 RFC 4033 DNS Security Introduction and Requirements March 2005
494
495
496 Insecure: The validating resolver has a trust anchor, a chain of
497 trust, and, at some delegation point, signed proof of the
498 non-existence of a DS record. This indicates that subsequent
499 branches in the tree are provably insecure. A validating resolver
500 may have a local policy to mark parts of the domain space as
501 insecure.
502
503 Bogus: The validating resolver has a trust anchor and a secure
504 delegation indicating that subsidiary data is signed, but the
505 response fails to validate for some reason: missing signatures,
506 expired signatures, signatures with unsupported algorithms, data
507 missing that the relevant NSEC RR says should be present, and so
508 forth.
509
510 Indeterminate: There is no trust anchor that would indicate that a
511 specific portion of the tree is secure. This is the default
512 operation mode.
513
514 This specification only defines how security-aware name servers can
515 signal non-validating stub resolvers that data was found to be bogus
516 (using RCODE=2, "Server Failure"; see [RFC4035]).
517
518 There is a mechanism for security-aware name servers to signal
519 security-aware stub resolvers that data was found to be secure (using
520 the AD bit; see [RFC4035]).
521
522 This specification does not define a format for communicating why
523 responses were found to be bogus or marked as insecure. The current
524 signaling mechanism does not distinguish between indeterminate and
525 insecure states.
526
527 A method for signaling advanced error codes and policy between a
528 security-aware stub resolver and security-aware recursive nameservers
529 is a topic for future work, as is the interface between a security-
530 aware resolver and the applications that use it. Note, however, that
531 the lack of the specification of such communication does not prohibit
532 deployment of signed zones or the deployment of security aware
533 recursive name servers that prohibit propagation of bogus data to the
534 applications.
535
536 6. Resolver Considerations
537
538 A security-aware resolver has to be able to perform cryptographic
539 functions necessary to verify digital signatures using at least the
540 mandatory-to-implement algorithm(s). Security-aware resolvers must
541 also be capable of forming an authentication chain from a newly
542 learned zone back to an authentication key, as described above. This
543 process might require additional queries to intermediate DNS zones to
544
545
546
547 Arends, et al. Standards Track [Page 10]
548 RFC 4033 DNS Security Introduction and Requirements March 2005
549
550
551 obtain necessary DNSKEY, DS, and RRSIG records. A security-aware
552 resolver should be configured with at least one trust anchor as the
553 starting point from which it will attempt to establish authentication
554 chains.
555
556 If a security-aware resolver is separated from the relevant
557 authoritative name servers by a recursive name server or by any sort
558 of intermediary device that acts as a proxy for DNS, and if the
559 recursive name server or intermediary device is not security-aware,
560 the security-aware resolver may not be capable of operating in a
561 secure mode. For example, if a security-aware resolver's packets are
562 routed through a network address translation (NAT) device that
563 includes a DNS proxy that is not security-aware, the security-aware
564 resolver may find it difficult or impossible to obtain or validate
565 signed DNS data. The security-aware resolver may have a particularly
566 difficult time obtaining DS RRs in such a case, as DS RRs do not
567 follow the usual DNS rules for ownership of RRs at zone cuts. Note
568 that this problem is not specific to NATs: any security-oblivious DNS
569 software of any kind between the security-aware resolver and the
570 authoritative name servers will interfere with DNSSEC.
571
572 If a security-aware resolver must rely on an unsigned zone or a name
573 server that is not security aware, the resolver may not be able to
574 validate DNS responses and will need a local policy on whether to
575 accept unverified responses.
576
577 A security-aware resolver should take a signature's validation period
578 into consideration when determining the TTL of data in its cache, to
579 avoid caching signed data beyond the validity period of the
580 signature. However, it should also allow for the possibility that
581 the security-aware resolver's own clock is wrong. Thus, a
582 security-aware resolver that is part of a security-aware recursive
583 name server will have to pay careful attention to the DNSSEC
584 "checking disabled" (CD) bit ([RFC4034]). This is in order to avoid
585 blocking valid signatures from getting through to other
586 security-aware resolvers that are clients of this recursive name
587 server. See [RFC4035] for how a secure recursive server handles
588 queries with the CD bit set.
589
590 7. Stub Resolver Considerations
591
592 Although not strictly required to do so by the protocol, most DNS
593 queries originate from stub resolvers. Stub resolvers, by
594 definition, are minimal DNS resolvers that use recursive query mode
595 to offload most of the work of DNS resolution to a recursive name
596 server. Given the widespread use of stub resolvers, the DNSSEC
597
598
599
600
601
602 Arends, et al. Standards Track [Page 11]
603 RFC 4033 DNS Security Introduction and Requirements March 2005
604
605
606 architecture has to take stub resolvers into account, but the
607 security features needed in a stub resolver differ in some respects
608 from those needed in a security-aware iterative resolver.
609
610 Even a security-oblivious stub resolver may benefit from DNSSEC if
611 the recursive name servers it uses are security-aware, but for the
612 stub resolver to place any real reliance on DNSSEC services, the stub
613 resolver must trust both the recursive name servers in question and
614 the communication channels between itself and those name servers.
615 The first of these issues is a local policy issue: in essence, a
616 security-oblivious stub resolver has no choice but to place itself at
617 the mercy of the recursive name servers that it uses, as it does not
618 perform DNSSEC validity checks on its own. The second issue requires
619 some kind of channel security mechanism; proper use of DNS
620 transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
621 TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
622 Particular implementations may have other choices available, such as
623 operating system specific interprocess communication mechanisms.
624 Confidentiality is not needed for this channel, but data integrity
625 and message authentication are.
626
627 A security-aware stub resolver that does trust both its recursive
628 name servers and its communication channel to them may choose to
629 examine the setting of the Authenticated Data (AD) bit in the message
630 header of the response messages it receives. The stub resolver can
631 use this flag bit as a hint to find out whether the recursive name
632 server was able to validate signatures for all of the data in the
633 Answer and Authority sections of the response.
634
635 There is one more step that a security-aware stub resolver can take
636 if, for whatever reason, it is not able to establish a useful trust
637 relationship with the recursive name servers that it uses: it can
638 perform its own signature validation by setting the Checking Disabled
639 (CD) bit in its query messages. A validating stub resolver is thus
640 able to treat the DNSSEC signatures as trust relationships between
641 the zone administrators and the stub resolver itself.
642
643 8. Zone Considerations
644
645 There are several differences between signed and unsigned zones. A
646 signed zone will contain additional security-related records (RRSIG,
647 DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be
648 generated by a signing process prior to serving the zone. The RRSIG
649 records that accompany zone data have defined inception and
650 expiration times that establish a validity period for the signatures
651 and the zone data the signatures cover.
652
653
654
655
656
657 Arends, et al. Standards Track [Page 12]
658 RFC 4033 DNS Security Introduction and Requirements March 2005
659
660
661 8.1. TTL Values vs. RRSIG Validity Period
662
663 It is important to note the distinction between a RRset's TTL value
664 and the signature validity period specified by the RRSIG RR covering
665 that RRset. DNSSEC does not change the definition or function of the
666 TTL value, which is intended to maintain database coherency in
667 caches. A caching resolver purges RRsets from its cache no later
668 than the end of the time period specified by the TTL fields of those
669 RRsets, regardless of whether the resolver is security-aware.
670
671 The inception and expiration fields in the RRSIG RR ([RFC4034]), on
672 the other hand, specify the time period during which the signature
673 can be used to validate the covered RRset. The signatures associated
674 with signed zone data are only valid for the time period specified by
675 these fields in the RRSIG RRs in question. TTL values cannot extend
676 the validity period of signed RRsets in a resolver's cache, but the
677 resolver may use the time remaining before expiration of the
678 signature validity period of a signed RRset as an upper bound for the
679 TTL of the signed RRset and its associated RRSIG RR in the resolver's
680 cache.
681
682 8.2. New Temporal Dependency Issues for Zones
683
684 Information in a signed zone has a temporal dependency that did not
685 exist in the original DNS protocol. A signed zone requires regular
686 maintenance to ensure that each RRset in the zone has a current valid
687 RRSIG RR. The signature validity period of an RRSIG RR is an
688 interval during which the signature for one particular signed RRset
689 can be considered valid, and the signatures of different RRsets in a
690 zone may expire at different times. Re-signing one or more RRsets in
691 a zone will change one or more RRSIG RRs, which will in turn require
692 incrementing the zone's SOA serial number to indicate that a zone
693 change has occurred and re-signing the SOA RRset itself. Thus,
694 re-signing any RRset in a zone may also trigger DNS NOTIFY messages
695 and zone transfer operations.
696
697 9. Name Server Considerations
698
699 A security-aware name server should include the appropriate DNSSEC
700 records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
701 from resolvers that have signaled their willingness to receive such
702 records via use of the DO bit in the EDNS header, subject to message
703 size limitations. Because inclusion of these DNSSEC RRs could easily
704 cause UDP message truncation and fallback to TCP, a security-aware
705 name server must also support the EDNS "sender's UDP payload"
706 mechanism.
707
708
709
710
711
712 Arends, et al. Standards Track [Page 13]
713 RFC 4033 DNS Security Introduction and Requirements March 2005
714
715
716 If possible, the private half of each DNSSEC key pair should be kept
717 offline, but this will not be possible for a zone for which DNS
718 dynamic update has been enabled. In the dynamic update case, the
719 primary master server for the zone will have to re-sign the zone when
720 it is updated, so the private key corresponding to the zone signing
721 key will have to be kept online. This is an example of a situation
722 in which the ability to separate the zone's DNSKEY RRset into zone
723 signing key(s) and key signing key(s) may be useful, as the key
724 signing key(s) in such a case can still be kept offline and may have
725 a longer useful lifetime than the zone signing key(s).
726
727 By itself, DNSSEC is not enough to protect the integrity of an entire
728 zone during zone transfer operations, as even a signed zone contains
729 some unsigned, nonauthoritative data if the zone has any children.
730 Therefore, zone maintenance operations will require some additional
731 mechanisms (most likely some form of channel security, such as TSIG,
732 SIG(0), or IPsec).
733
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
734 10. DNS Security Document Family
735
736 The DNSSEC document set can be partitioned into several main groups,
737 under the larger umbrella of the DNS base protocol documents.
738
739 The "DNSSEC protocol document set" refers to the three documents that
740 form the core of the DNS security extensions:
741
742 1. DNS Security Introduction and Requirements (this document)
743
744 2. Resource Records for DNS Security Extensions [RFC4034]
745
746 3. Protocol Modifications for the DNS Security Extensions [RFC4035]
747
748 Additionally, any document that would add to or change the core DNS
749 Security extensions would fall into this category. This includes any
750 future work on the communication between security-aware stub
751 resolvers and upstream security-aware recursive name servers.
752
753 The "Digital Signature Algorithm Specification" document set refers
754 to the group of documents that describe how specific digital
755 signature algorithms should be implemented to fit the DNSSEC resource
756 record format. Each document in this set deals with a specific
757 digital signature algorithm. Please see the appendix on "DNSSEC
758 Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
759 that were defined when this core specification was written.
760
761 The "Transaction Authentication Protocol" document set refers to the
762 group of documents that deal with DNS message authentication,
763 including secret key establishment and verification. Although not
764
765
766
767 Arends, et al. Standards Track [Page 14]
768 RFC 4033 DNS Security Introduction and Requirements March 2005
769
770
771 strictly part of the DNSSEC specification as defined in this set of
772 documents, this group is noted because of its relationship to DNSSEC.
773
774 The final document set, "New Security Uses", refers to documents that
775 seek to use proposed DNS Security extensions for other security
776 related purposes. DNSSEC does not provide any direct security for
777 these new uses but may be used to support them. Documents that fall
778 in this category include those describing the use of DNS in the
779 storage and distribution of certificates ([RFC2538]).
780
781 11. IANA Considerations
782
783 This overview document introduces no new IANA considerations. Please
784 see [RFC4034] for a complete review of the IANA considerations
785 introduced by DNSSEC.
786
787 12. Security Considerations
788
789 This document introduces DNS security extensions and describes the
790 document set that contains the new security records and DNS protocol
791 modifications. The extensions provide data origin authentication and
792 data integrity using digital signatures over resource record sets.
793 This section discusses the limitations of these extensions.
794
795 In order for a security-aware resolver to validate a DNS response,
796 all zones along the path from the trusted starting point to the zone
797 containing the response zones must be signed, and all name servers
798 and resolvers involved in the resolution process must be
799 security-aware, as defined in this document set. A security-aware
800 resolver cannot verify responses originating from an unsigned zone,
801 from a zone not served by a security-aware name server, or for any
802 DNS data that the resolver is only able to obtain through a recursive
803 name server that is not security-aware. If there is a break in the
804 authentication chain such that a security-aware resolver cannot
805 obtain and validate the authentication keys it needs, then the
806 security-aware resolver cannot validate the affected DNS data.
807
808 This document briefly discusses other methods of adding security to a
809 DNS query, such as using a channel secured by IPsec or using a DNS
810 transaction authentication mechanism such as TSIG ([RFC2845]) or
811 SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
812 per se.
813
814 A non-validating security-aware stub resolver, by definition, does
815 not perform DNSSEC signature validation on its own and thus is
816 vulnerable both to attacks on (and by) the security-aware recursive
817 name servers that perform these checks on its behalf and to attacks
818 on its communication with those security-aware recursive name
819
820
821
822 Arends, et al. Standards Track [Page 15]
823 RFC 4033 DNS Security Introduction and Requirements March 2005
824
825
826 servers. Non-validating security-aware stub resolvers should use
827 some form of channel security to defend against the latter threat.
828 The only known defense against the former threat would be for the
829 security-aware stub resolver to perform its own signature validation,
830 at which point, again by definition, it would no longer be a
831 non-validating security-aware stub resolver.
832
833 DNSSEC does not protect against denial of service attacks. DNSSEC
834 makes DNS vulnerable to a new class of denial of service attacks
835 based on cryptographic operations against security-aware resolvers
836 and security-aware name servers, as an attacker can attempt to use
837 DNSSEC mechanisms to consume a victim's resources. This class of
838 attacks takes at least two forms. An attacker may be able to consume
839 resources in a security-aware resolver's signature validation code by
840 tampering with RRSIG RRs in response messages or by constructing
841 needlessly complex signature chains. An attacker may also be able to
842 consume resources in a security-aware name server that supports DNS
843 dynamic update, by sending a stream of update messages that force the
844 security-aware name server to re-sign some RRsets in the zone more
845 frequently than would otherwise be necessary.
846
847 Due to a deliberate design choice, DNSSEC does not provide
848 confidentiality.
849
850 DNSSEC introduces the ability for a hostile party to enumerate all
851 the names in a zone by following the NSEC chain. NSEC RRs assert
852 which names do not exist in a zone by linking from existing name to
853 existing name along a canonical ordering of all the names within a
854 zone. Thus, an attacker can query these NSEC RRs in sequence to
855 obtain all the names in a zone. Although this is not an attack on
856 the DNS itself, it could allow an attacker to map network hosts or
857 other resources by enumerating the contents of a zone.
858
859 DNSSEC introduces significant additional complexity to the DNS and
860 thus introduces many new opportunities for implementation bugs and
861 misconfigured zones. In particular, enabling DNSSEC signature
862 validation in a resolver may cause entire legitimate zones to become
863 effectively unreachable due to DNSSEC configuration errors or bugs.
864
865 DNSSEC does not protect against tampering with unsigned zone data.
866 Non-authoritative data at zone cuts (glue and NS RRs in the parent
867 zone) are not signed. This does not pose a problem when validating
868 the authentication chain, but it does mean that the non-authoritative
869 data itself is vulnerable to tampering during zone transfer
870 operations. Thus, while DNSSEC can provide data origin
871 authentication and data integrity for RRsets, it cannot do so for
872 zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
873 used to protect zone transfer operations.
874
875
876
877 Arends, et al. Standards Track [Page 16]
878 RFC 4033 DNS Security Introduction and Requirements March 2005
879
880
881 Please see [RFC4034] and [RFC4035] for additional security
882 considerations.
883
884 13. Acknowledgements
885
886 This document was created from the input and ideas of the members of
887 the DNS Extensions Working Group. Although explicitly listing
888 everyone who has contributed during the decade in which DNSSEC has
889 been under development would be impossible, the editors would
890 particularly like to thank the following people for their
891 contributions to and comments on this document set: Jaap Akkerhuis,
892 Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
893 David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
894 Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
895 Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip
896 Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
897 Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
898 Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
899 Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
900 Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
901 Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
902 Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
903 Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
904 Brian Wellington, and Suzanne Woolf.
905
906 No doubt the above list is incomplete. We apologize to anyone we
907 left out.
908
909 14. References
910
911 14.1. Normative References
912
913 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
914 STD 13, RFC 1034, November 1987.
915
916 [RFC1035] Mockapetris, P., "Domain names - implementation and
917 specification", STD 13, RFC 1035, November 1987.
918
919 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
920 Extensions", RFC 2535, March 1999.
921
922 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
923 2671, August 1999.
924
925 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
926 3225, December 2001.
927
928
929
930
931
932 Arends, et al. Standards Track [Page 17]
933 RFC 4033 DNS Security Introduction and Requirements March 2005
934
935
936 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
937 message size requirements", RFC 3226, December 2001.
938
939 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
940 Resource Record (RR)", RFC 3445, December 2002.
941
942 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
943 Rose, "Resource Records for DNS Security Extensions", RFC
944 4034, March 2005.
945
946 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
947 Rose, "Protocol Modifications for the DNS Security
948 Extensions", RFC 4035, March 2005.
949
950 14.2. Informative References
951
952 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
953 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
954 RFC 2136, April 1997.
955
956 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
957 Specification", RFC 2181, July 1997.
958
959 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
960 NCACHE)", RFC 2308, March 1998.
961
962 [RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates
963 in the Domain Name System (DNS)", RFC 2538, March 1999.
964
965 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
966 Wellington, "Secret Key Transaction Authentication for DNS
967 (TSIG)", RFC 2845, May 2000.
968
969 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
970 ( SIG(0)s )", RFC 2931, September 2000.
971
972 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
973 Update", RFC 3007, November 2000.
974
975 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
976 Signing Authority", RFC 3008, November 2000.
977
978 [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
979 Status", RFC 3090, March 2001.
980
981 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
982 (RR) Types", RFC 3597, September 2003.
983
984
985
986
987 Arends, et al. Standards Track [Page 18]
988 RFC 4033 DNS Security Introduction and Requirements March 2005
989
990
991 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
992 Authenticated Data (AD) bit", RFC 3655, November 2003.
993
994 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
995 (RR)", RFC 3658, December 2003.
996
997 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
998 Signer (DS)", RFC 3755, May 2004.
999
1000 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
1001 System KEY (DNSKEY) Resource Record (RR) Secure Entry
1002 Point (SEP) Flag", RFC 3757, April 2004.
1003
1004 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
1005 Name System (DNS)", RFC 3833, August 2004.
1006
1007 [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
1008 RDATA Format", RFC 3845, August 2004.
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Arends, et al. Standards Track [Page 19]
1043 RFC 4033 DNS Security Introduction and Requirements March 2005
1044
1045
1046 Authors' Addresses
1047
1048 Roy Arends
1049 Telematica Instituut
1050 Brouwerijstraat 1
1051 7523 XC Enschede
1052 NL
1053
1054 EMail: roy.arends@telin.nl
1055
1056
1057 Rob Austein
1058 Internet Systems Consortium
1059 950 Charter Street
1060 Redwood City, CA 94063
1061 USA
1062
1063 EMail: sra@isc.org
1064
1065
1066 Matt Larson
1067 VeriSign, Inc.
1068 21345 Ridgetop Circle
1069 Dulles, VA 20166-6503
1070 USA
1071
1072 EMail: mlarson@verisign.com
1073
1074
1075 Dan Massey
1076 Colorado State University
1077 Department of Computer Science
1078 Fort Collins, CO 80523-1873
1079
1080 EMail: massey@cs.colostate.edu
1081
1082
1083 Scott Rose
1084 National Institute for Standards and Technology
1085 100 Bureau Drive
1086 Gaithersburg, MD 20899-8920
1087 USA
1088
1089 EMail: scott.rose@nist.gov
1090
1091
1092
1093
1094
1095
1096
1097 Arends, et al. Standards Track [Page 20]
1098 RFC 4033 DNS Security Introduction and Requirements March 2005
1099
1100
1101 Full Copyright Statement
1102
1103 Copyright (C) The Internet Society (2005).
1104
1105 This document is subject to the rights, licenses and restrictions
1106 contained in BCP 78, and except as set forth therein, the authors
1107 retain all their rights.
1108
1109 This document and the information contained herein are provided on an
1110 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1111 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1112 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1113 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1114 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1115 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1116
1117 Intellectual Property
1118
1119 The IETF takes no position regarding the validity or scope of any
1120 Intellectual Property Rights or other rights that might be claimed to
1121 pertain to the implementation or use of the technology described in
1122 this document or the extent to which any license under such rights
1123 might or might not be available; nor does it represent that it has
1124 made any independent effort to identify any such rights. Information
1125 on the procedures with respect to rights in RFC documents can be
1126 found in BCP 78 and BCP 79.
1127
1128 Copies of IPR disclosures made to the IETF Secretariat and any
1129 assurances of licenses to be made available, or the result of an
1130 attempt made to obtain a general license or permission for the use of
1131 such proprietary rights by implementers or users of this
1132 specification can be obtained from the IETF on-line IPR repository at
1133 http://www.ietf.org/ipr.
1134
1135 The IETF invites any interested party to bring to its attention any
1136 copyrights, patents or patent applications, or other proprietary
1137 rights that may cover technology that may be required to implement
1138 this standard. Please address the information to the IETF at ietf-
1139 ipr@ietf.org.
1140
1141 Acknowledgement
1142
1143 Funding for the RFC Editor function is currently provided by the
1144 Internet Society.
1145
1146
1147
1148
1149
1150
1151
1152 Arends, et al. Standards Track [Page 21]
1153