5 Internet-Draft Telematica Instituut
6 Expires: January 19, 2006 M. Kosters
13 draft-ietf-dnsext-dnssec-opt-in-07
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she becomes
20 aware will be disclosed, in accordance with Section 6 of BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on January 19, 2006.
42 Copyright (C) The Internet Society (2005).
46 In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
47 4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
48 cryptographically secured. Maintaining this cryptography is not
49 practical or necessary. This document describes an experimental
50 "Opt-In" model that allows administrators to omit this cryptography
51 and manage the cost of adopting DNSSEC with large zones.
55 Arends, et al. Expires January 19, 2006 [Page 1]
57 Internet-Draft DNSSEC Opt-In July 2005
62 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4
65 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4
66 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5
67 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5
68 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6
69 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6
70 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7
71 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7
72 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7
73 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7
74 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8
75 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8
76 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
78 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10
79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
83 11.1 Normative References . . . . . . . . . . . . . . . . . . . 13
84 11.2 Informative References . . . . . . . . . . . . . . . . . . 13
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
86 A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14
87 Intellectual Property and Copyright Statements . . . . . . . . 16
111 Arends, et al. Expires January 19, 2006 [Page 2]
113 Internet-Draft DNSSEC Opt-In July 2005
116 1. Definitions and Terminology
118 Throughout this document, familiarity with the DNS system (RFC 1035
119 [1]), DNS security extensions ([3], [4], and [5], referred to in this
120 document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
123 The following abbreviations and terms are used in this document:
125 RR: is used to refer to a DNS resource record.
126 RRset: refers to a Resource Record Set, as defined by [8]. In this
127 document, the RRset is also defined to include the covering RRSIG
128 records, if any exist.
129 signed name: refers to a DNS name that has, at minimum, a (signed)
131 unsigned name: refers to a DNS name that does not (at least) have a
133 covering NSEC record/RRset: is the NSEC record used to prove
134 (non)existence of a particular name or RRset. This means that for
135 a RRset or name 'N', the covering NSEC record has the name 'N', or
136 has an owner name less than 'N' and "next" name greater than 'N'.
137 delegation: refers to a NS RRset with a name different from the
138 current zone apex (non-zone-apex), signifying a delegation to a
140 secure delegation: refers to a signed name containing a delegation
141 (NS RRset), and a signed DS RRset, signifying a delegation to a
143 insecure delegation: refers to a signed name containing a delegation
144 (NS RRset), but lacking a DS RRset, signifying a delegation to an
146 Opt-In insecure delegation: refers to an unsigned name containing
147 only a delegation NS RRset. The covering NSEC record uses the
148 Opt-In methodology described in this document.
150 The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
152 document are to be interpreted as described in RFC 2119 [7].
156 The cost to cryptographically secure delegations to unsigned zones is
157 high for large delegation-centric zones and zones where insecure
158 delegations will be updated rapidly. For these zones, the costs of
159 maintaining the NSEC record chain may be extremely high relative to
160 the gain of cryptographically authenticating existence of unsecured
163 This document describes an experimental method of eliminating the
167 Arends, et al. Expires January 19, 2006 [Page 3]
169 Internet-Draft DNSSEC Opt-In July 2005
172 superfluous cryptography present in secure delegations to unsigned
173 zones. Using "Opt-In", a zone administrator can choose to remove
174 insecure delegations from the NSEC chain. This is accomplished by
175 extending the semantics of the NSEC record by using a redundant bit
178 3. Experimental Status
180 This document describes an EXPERIMENTAL extension to DNSSEC. It
181 interoperates with non-experimental DNSSEC using the technique
182 described in [6]. This experiment is identified with the following
183 private algorithms (using algorithm 253):
185 "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
187 "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
190 Servers wishing to sign and serve zones that utilize Opt-In MUST sign
191 the zone with only one or more of these private algorithms. This
192 requires the signing tools and servers to support private algorithms,
195 Resolvers wishing to validate Opt-In zones MUST only do so when the
196 zone is only signed using one or more of these private algorithms.
198 The remainder of this document assumes that the servers and resolvers
199 involved are aware of and are involved in this experiment.
201 4. Protocol Additions
203 In DNSSEC, delegation NS RRsets are not signed, but are instead
204 accompanied by a NSEC RRset of the same name and (possibly) a DS
205 record. The security status of the subzone is determined by the
206 presence or absence of the DS RRset, cryptographically proven by the
207 NSEC record. Opt-In expands this definition by allowing insecure
208 delegations to exist within an otherwise signed zone without the
209 corresponding NSEC record at the delegation's owner name. These
210 insecure delegations are proven insecure by using a covering NSEC
213 Since this represents a change of the interpretation of NSEC records,
214 resolvers must be able to distinguish between RFC standard DNSSEC
215 NSEC records and Opt-In NSEC records. This is accomplished by
216 "tagging" the NSEC records that cover (or potentially cover) insecure
217 delegation nodes. This tag is indicated by the absence of the NSEC
218 bit in the type map. Since the NSEC bit in the type map merely
219 indicates the existence of the record itself, this bit is redundant
223 Arends, et al. Expires January 19, 2006 [Page 4]
225 Internet-Draft DNSSEC Opt-In July 2005
228 and safe for use as a tag.
230 An Opt-In tagged NSEC record does not assert the (non)existence of
231 the delegations that it covers (except for a delegation with the same
232 name). This allows for the addition or removal of these delegations
233 without recalculating or resigning records in the NSEC chain.
234 However, Opt-In tagged NSEC records do assert the (non)existence of
237 An Opt-In NSEC record MAY have the same name as an insecure
238 delegation. In this case, the delegation is proven insecure by the
239 lack of a DS bit in type map and the signed NSEC record does assert
240 the existence of the delegation.
242 Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
243 records and standard DNSSEC NSEC records. If a NSEC record is not
244 Opt-In, there MUST NOT be any insecure delegations (or any other
245 records) between it and the RRsets indicated by the 'next domain
246 name' in the NSEC RDATA. If it is Opt-In, there MUST only be
247 insecure delegations between it and the next node indicated by the
248 'next domain name' in the NSEC RDATA.
252 o An Opt-In NSEC type is identified by a zero-valued (or not-
253 specified) NSEC bit in the type bit map of the NSEC record.
254 o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
255 the type bit map of the NSEC record.
259 o An Opt-In NSEC record does not assert the non-existence of a name
260 between its owner name and "next" name, although it does assert
261 that any name in this span MUST be an insecure delegation.
262 o An Opt-In NSEC record does assert the (non)existence of RRsets
263 with the same owner name.
265 4.1 Server Considerations
267 Opt-In imposes some new requirements on authoritative DNS servers.
269 4.1.1 Delegations Only
271 This specification dictates that only insecure delegations may exist
272 between the owner and "next" names of an Opt-In tagged NSEC record.
273 Signing tools SHOULD NOT generate signed zones that violate this
274 restriction. Servers SHOULD refuse to load and/or serve zones that
275 violate this restriction. Servers also SHOULD reject AXFR or IXFR
279 Arends, et al. Expires January 19, 2006 [Page 5]
281 Internet-Draft DNSSEC Opt-In July 2005
284 responses that violate this restriction.
286 4.1.2 Insecure Delegation Responses
288 When returning an Opt-In insecure delegation, the server MUST return
289 the covering NSEC RRset in the Authority section.
291 In standard DNSSEC, NSEC records already must be returned along with
292 the insecure delegation. The primary difference that this proposal
293 introduces is that the Opt-In tagged NSEC record will have a
294 different owner name from the delegation RRset. This may require
295 implementations to search for the covering NSEC RRset.
297 4.1.3 Wildcards and Opt-In
299 Standard DNSSEC describes the practice of returning NSEC records to
300 prove the non-existence of an applicable wildcard in non-existent
301 name responses. This NSEC record can be described as a "negative
302 wildcard proof". The use of Opt-In NSEC records changes the
303 necessity for this practice. For non-existent name responses when
304 the query name (qname) is covered by an Opt-In tagged NSEC record,
305 servers MAY choose to omit the wildcard proof record, and clients
306 MUST NOT treat the absence of this NSEC record as a validation error.
308 The intent of the standard DNSSEC negative wildcard proof requirement
309 is to prevent malicious users from undetectably removing valid
310 wildcard responses. In order for this cryptographic proof to work,
311 the resolver must be able to prove:
313 1. The exact qname does not exist. This is done by the "normal"
315 2. No applicable wildcard exists. This is done by returning a NSEC
316 record proving that the wildcard does not exist (this is the
317 negative wildcard proof).
319 However, if the NSEC record covering the exact qname is an Opt-In
320 NSEC record, the resolver will not be able to prove the first part of
321 this equation, as the qname might exist as an insecure delegation.
322 Thus, since the total proof cannot be completed, the negative
323 wildcard proof NSEC record is not useful.
325 The negative wildcard proof is also not useful when returned as part
326 of an Opt-In insecure delegation response for a similar reason: the
327 resolver cannot prove that the qname does or does not exist, and
328 therefore cannot prove that a wildcard expansion is valid.
330 The presence of an Opt-In tagged NSEC record does not change the
331 practice of returning a NSEC along with a wildcard expansion. Even
335 Arends, et al. Expires January 19, 2006 [Page 6]
337 Internet-Draft DNSSEC Opt-In July 2005
340 though the Opt-In NSEC will not be able to prove that the wildcard
341 expansion is valid, it will prove that the wildcard expansion is not
342 masking any signed records.
346 Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In
347 particular, it introduces the need for rules that describe when to
348 add or remove a delegation name from the NSEC chain. This document
349 does not attempt to define these rules. Until these rules are
350 defined, servers MUST NOT process DNS Dynamic Update requests against
351 zones that use Opt-In NSEC records. Servers SHOULD return responses
352 to update requests with RCODE=REFUSED.
354 4.2 Client Considerations
356 Opt-In imposes some new requirements on security-aware resolvers
357 (caching or otherwise).
359 4.2.1 Delegations Only
361 As stated in the "Server Considerations" section above, this
362 specification restricts the namespace covered by Opt-In tagged NSEC
363 records to insecure delegations only. Thus, resolvers MUST reject as
364 invalid any records that fall within an Opt-In NSEC record's span
365 that are not NS records or corresponding glue records.
367 4.2.2 Validation Process Changes
369 This specification does not change the resolver's resolution
370 algorithm. However, it does change the DNSSEC validation process.
371 Resolvers MUST be able to use Opt-In tagged NSEC records to
372 cryptographically prove the validity and security status (as
373 insecure) of a referral. Resolvers determine the security status of
374 the referred-to zone as follows:
376 o In standard DNSSEC, the security status is proven by the existence
377 or absence of a DS RRset at the same name as the delegation. The
378 existence of the DS RRset indicates that the referred-to zone is
379 signed. The absence of the DS RRset is proven using a verified
380 NSEC record of the same name that does not have the DS bit set in
381 the type map. This NSEC record MAY also be tagged as Opt-In.
382 o Using Opt-In, the security status is proven by the existence of a
383 DS record (for signed) or the presence of a verified Opt-In tagged
384 NSEC record that covers the delegation name. That is, the NSEC
385 record does not have the NSEC bit set in the type map, and the
386 delegation name falls between the NSEC's owner and "next" name.
391 Arends, et al. Expires January 19, 2006 [Page 7]
393 Internet-Draft DNSSEC Opt-In July 2005
396 Using Opt-In does not substantially change the nature of following
397 referrals within DNSSEC. At every delegation point, the resolver
398 will have cryptographic proof that the referred-to subzone is signed
401 When receiving either an Opt-In insecure delegation response or a
402 non-existent name response where that name is covered by an Opt-In
403 tagged NSEC record, the resolver MUST NOT require proof (in the form
404 of a NSEC record) that a wildcard did not exist.
406 4.2.3 NSEC Record Caching
408 Caching resolvers MUST be able to retrieve the appropriate covering
409 Opt-In NSEC record when returning referrals that need them. This
410 requirement differs from standard DNSSEC in that the covering NSEC
411 will not have the same owner name as the delegation. Some
412 implementations may have to use new methods for finding these NSEC
415 4.2.4 Use of the AD bit
417 The AD bit, as defined by [2] and [5], MUST NOT be set when:
419 o sending a Name Error (RCODE=3) response where the covering NSEC is
421 o sending an Opt-In insecure delegation response, unless the
422 covering (Opt-In) NSEC record's owner name equals the delegation
425 This rule is based on what the Opt-In NSEC record actually proves:
426 for names that exist between the Opt-In NSEC record's owner and
427 "next" names, the Opt-In NSEC record cannot prove the non-existence
428 or existence of the name. As such, not all data in the response has
429 been cryptographically verified, so the AD bit cannot be set.
433 Using Opt-In allows administrators of large and/or changing
434 delegation-centric zones to minimize the overhead involved in
435 maintaining the security of the zone.
437 Opt-In accomplishes this by eliminating the need for NSEC records for
438 insecure delegations. This, in a zone with a large number of
439 delegations to unsigned subzones, can lead to substantial space
440 savings (both in memory and on disk). Additionally, Opt-In allows
441 for the addition or removal of insecure delegations without modifying
442 the NSEC record chain. Zones that are frequently updating insecure
443 delegations (e.g., TLDs) can avoid the substantial overhead of
447 Arends, et al. Expires January 19, 2006 [Page 8]
449 Internet-Draft DNSSEC Opt-In July 2005
452 modifying and resigning the affected NSEC records.
456 Consider the zone EXAMPLE, shown below. This is a zone where all of
457 the NSEC records are tagged as Opt-In.
459 Example A: Fully Opt-In Zone.
462 EXAMPLE. RRSIG SOA ...
463 EXAMPLE. NS FIRST-SECURE.EXAMPLE.
464 EXAMPLE. RRSIG NS ...
466 EXAMPLE. RRSIG DNSKEY ...
467 EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (
468 SOA NS RRSIG DNSKEY )
469 EXAMPLE. RRSIG NSEC ...
471 FIRST-SECURE.EXAMPLE. A ...
472 FIRST-SECURE.EXAMPLE. RRSIG A ...
473 FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG
474 FIRST-SECURE.EXAMPLE. RRSIG NSEC ...
476 NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
477 NS.NOT-SECURE.EXAMPLE. A ...
479 NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
480 NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG
481 NOT-SECURE-2.EXAMPLE RRSIG NSEC ...
483 SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
484 SECOND-SECURE.EXAMPLE. DS ...
485 SECOND-SECURE.EXAMPLE. RRSIG DS ...
486 SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY
487 SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
489 UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE.
490 NS.UNSIGNED.EXAMPLE. A ...
493 In this example, a query for a signed RRset (e.g., "FIRST-
494 SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
495 SECURE.EXAMPLE A") will result in a standard DNSSEC response.
497 A query for a nonexistent RRset will result in a response that
498 differs from standard DNSSEC by: the NSEC record will be tagged as
499 Opt-In, there may be no NSEC record proving the non-existence of a
503 Arends, et al. Expires January 19, 2006 [Page 9]
505 Internet-Draft DNSSEC Opt-In July 2005
508 matching wildcard record, and the AD bit will not be set.
510 A query for an insecure delegation RRset (or a referral) will return
511 both the answer (in the Authority section) and the corresponding
512 Opt-In NSEC record to prove that it is not secure.
514 Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
522 UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
523 SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS
524 SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
527 NS.UNSIGNED.EXAMPLE. A ...
529 In the Example A.1 zone, the EXAMPLE. node MAY use either style of
530 NSEC record, because there are no insecure delegations that occur
531 between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
532 Example A would still be a valid zone if the NSEC record for EXAMPLE.
533 was changed to the following RR:
535 EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS
538 However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
539 SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure
540 delegations in the range they define. (NOT-SECURE.EXAMPLE. and
541 UNSIGNED.EXAMPLE., respectively).
543 NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
544 part of the NSEC chain and also covered by an Opt-In tagged NSEC
545 record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
546 removed from the zone without modifying and resigning the prior NSEC
547 record. Delegations with names that fall between NOT-SECURE-
548 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
549 resigning any NSEC records.
553 Opt-In is not backwards compatible with standard DNSSEC and is
554 considered experimental. Standard DNSSEC compliant implementations
555 would not recognize Opt-In tagged NSEC records as different from
559 Arends, et al. Expires January 19, 2006 [Page 10]
561 Internet-Draft DNSSEC Opt-In July 2005
564 standard NSEC records. Because of this, standard DNSSEC
565 implementations, if they were to validate Opt-In style responses,
566 would reject all Opt-In insecure delegations within a zone as
567 invalid. However, by only signing with private algorithms, standard
568 DNSSEC implementations will treat Opt-In responses as unsigned.
570 It should be noted that all elements in the resolution path between
571 (and including) the validator and the authoritative name server must
572 be aware of the Opt-In experiment and implement the Opt-In semantics
573 for successful validation to be possible. In particular, this
574 includes any caching middleboxes between the validator and
575 authoritative name server.
577 8. Security Considerations
579 Opt-In allows for unsigned names, in the form of delegations to
580 unsigned subzones, to exist within an otherwise signed zone. All
581 unsigned names are, by definition, insecure, and their validity or
582 existence cannot by cryptographically proven.
586 o Records with unsigned names (whether existing or not) suffer from
587 the same vulnerabilities as records in an unsigned zone. These
588 vulnerabilities are described in more detail in [12] (note in
589 particular sections 2.3, "Name Games" and 2.6, "Authenticated
591 o Records with signed names have the same security whether or not
594 Note that with or without Opt-In, an insecure delegation may have its
595 contents undetectably altered by an attacker. Because of this, the
596 primary difference in security that Opt-In introduces is the loss of
597 the ability to prove the existence or nonexistence of an insecure
598 delegation within the span of an Opt-In NSEC record.
600 In particular, this means that a malicious entity may be able to
601 insert or delete records with unsigned names. These records are
602 normally NS records, but this also includes signed wildcard
603 expansions (while the wildcard record itself is signed, its expanded
604 name is an unsigned name).
606 For example, if a resolver received the following response from the
615 Arends, et al. Expires January 19, 2006 [Page 11]
617 Internet-Draft DNSSEC Opt-In July 2005
620 Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
627 DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
628 EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
630 EXAMPLE. RRSIG NSEC ...
635 The resolver would have no choice but to believe that the referral to
636 NS.FORGED. is valid. If a wildcard existed that would have been
637 expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
638 have undetectably removed it and replaced it with the forged
641 Note that being able to add a delegation is functionally equivalent
642 to being able to add any record type: an attacker merely has to forge
643 a delegation to nameserver under his/her control and place whatever
644 records needed at the subzone apex.
646 While in particular cases, this issue may not present a significant
647 security problem, in general it should not be lightly dismissed.
648 Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
649 In particular, zone signing tools SHOULD NOT default to Opt-In, and
650 MAY choose to not support Opt-In at all.
652 9. IANA Considerations
658 The contributions, suggestions and remarks of the following persons
659 (in alphabetic order) to this draft are acknowledged:
661 Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
662 Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
663 Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
671 Arends, et al. Expires January 19, 2006 [Page 12]
673 Internet-Draft DNSSEC Opt-In July 2005
676 11.1 Normative References
678 [1] Mockapetris, P., "Domain names - implementation and
679 specification", STD 13, RFC 1035, November 1987.
681 [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
682 Authenticated Data (AD) bit", RFC 3655, November 2003.
684 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
685 "DNS Security Introduction and Requirements", RFC 4033,
688 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
689 "Resource Records for the DNS Security Extensions", RFC 4034,
692 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
693 "Protocol Modifications for the DNS Security Extensions",
694 RFC 4035, March 2005.
696 [6] Blacka, D., "DNSSEC Experiments",
697 draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
700 11.2 Informative References
702 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
703 Levels", BCP 14, RFC 2119, March 1997.
705 [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
708 [9] Eastlake, D., "Secure Domain Name System Dynamic Update",
709 RFC 2137, April 1997.
711 [10] Lewis, E., "DNS Security Extension Clarification on Zone
712 Status", RFC 3090, March 2001.
714 [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
717 [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
718 System (DNS)", RFC 3833, August 2004.
727 Arends, et al. Expires January 19, 2006 [Page 13]
729 Internet-Draft DNSSEC Opt-In July 2005
740 Email: roy.arends@telin.nl
745 21355 Ridgetop Circle
749 Phone: +1 703 948 3200
750 Email: markk@verisign.com
751 URI: http://www.verisignlabs.com
756 21355 Ridgetop Circle
760 Phone: +1 703 948 3200
761 Email: davidb@verisign.com
762 URI: http://www.verisignlabs.com
764 Appendix A. Implementing Opt-In using "Views"
766 In many cases, it may be convenient to implement an Opt-In zone by
767 combining two separately maintained "views" of a zone at request
768 time. In this context, "view" refers to a particular version of a
769 zone, not to any specific DNS implementation feature.
771 In this scenario, one view is the secure view, the other is the
772 insecure (or legacy) view. The secure view consists of an entirely
773 signed zone using Opt-In tagged NSEC records. The insecure view
774 contains no DNSSEC information. It is helpful, although not
775 necessary, for the secure view to be a subset (minus DNSSEC records)
776 of the insecure view.
778 In addition, the only RRsets that may solely exist in the insecure
779 view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and
783 Arends, et al. Expires January 19, 2006 [Page 14]
785 Internet-Draft DNSSEC Opt-In July 2005
788 the zone apex NS RRset) MUST be signed and in the secure view.
790 These two views may be combined at request time to provide a virtual,
791 single Opt-In zone. The following algorithm is used when responding
793 V_A is the secure view as described above.
794 V_B is the insecure view as described above.
795 R_A is a response generated from V_A, following RFC 2535bis.
796 R_B is a response generated from V_B, following DNS resolution as
798 R_C is the response generated by combining R_A with R_B, as
800 A query is DNSSEC-aware if it either has the DO bit [11] turned
801 on, or is for a DNSSEC-specific record type.
805 1. If V_A is a subset of V_B and the query is not DNSSEC-aware,
806 generate and return R_B, otherwise
808 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise
809 4. Generate R_B and combine it with R_A to form R_C:
810 For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
811 records from R_A into R_B, EXCEPT the AUTHORITY section SOA
812 record, if R_B's RCODE = NOERROR.
839 Arends, et al. Expires January 19, 2006 [Page 15]
841 Internet-Draft DNSSEC Opt-In July 2005
844 Intellectual Property Statement
846 The IETF takes no position regarding the validity or scope of any
847 Intellectual Property Rights or other rights that might be claimed to
848 pertain to the implementation or use of the technology described in
849 this document or the extent to which any license under such rights
850 might or might not be available; nor does it represent that it has
851 made any independent effort to identify any such rights. Information
852 on the procedures with respect to rights in RFC documents can be
853 found in BCP 78 and BCP 79.
855 Copies of IPR disclosures made to the IETF Secretariat and any
856 assurances of licenses to be made available, or the result of an
857 attempt made to obtain a general license or permission for the use of
858 such proprietary rights by implementers or users of this
859 specification can be obtained from the IETF on-line IPR repository at
860 http://www.ietf.org/ipr.
862 The IETF invites any interested party to bring to its attention any
863 copyrights, patents or patent applications, or other proprietary
864 rights that may cover technology that may be required to implement
865 this standard. Please address the information to the IETF at
869 Disclaimer of Validity
871 This document and the information contained herein are provided on an
872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
874 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
875 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
876 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
882 Copyright (C) The Internet Society (2005). This document is subject
883 to the rights, licenses and restrictions contained in BCP 78, and
884 except as set forth therein, the authors retain all their rights.
889 Funding for the RFC Editor function is currently provided by the
895 Arends, et al. Expires January 19, 2006 [Page 16]