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