3 INTERNET-DRAFT Samuel Weiler
4 Expires: June 2004 December 15, 2003
5 Updates: RFC 2535, [DS]
7 Legacy Resolver Compatibility for Delegation Signer
8 draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
12 This document is an Internet-Draft and is subject to all provisions
13 of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as
20 Internet-Drafts are draft documents valid for a maximum of six
21 months and may be updated, replaced, or obsoleted by other
22 documents at any time. It is inappropriate to use Internet-Drafts
23 as reference material or to cite them other than as "work in
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/1id-abstracts.html
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html
32 Comments should be sent to the author or to the DNSEXT WG mailing
33 list: namedroppers@ops.ietf.org
37 As the DNS Security (DNSSEC) specifications have evolved, the
38 syntax and semantics of the DNSSEC resource records (RRs) have
39 changed. Many deployed nameservers understand variants of these
40 semantics. Dangerous interactions can occur when a resolver that
41 understands an earlier version of these semantics queries an
42 authoritative server that understands the new delegation signer
43 semantics, including at least one failure scenario that will cause
44 an unsecured zone to be unresolvable. This document changes the
45 type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
46 avoid those interactions.
48 Changes between 05 and 06:
50 Signifigantly reworked the IANA section -- went back to one
53 Removed Diffie-Hellman from the list of zone-signing algorithms
54 (leaving only DSA, RSA/SHA-1, and private algorithms).
56 Added a DNSKEY flags field registry.
58 Changes between 04 and 05:
60 IESG approved publication.
62 Cleaned up an internal reference in the acknowledgements section.
64 Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
66 Changed the names of both new registries. Added algorithm
67 mnemonics to the new zone signing algorithm registry. Minor
68 rewording in the IANA section for clarity.
70 Cleaned up formatting of references. Replaced unknown-rr draft
71 references with RFC3597. Bumped DS version number.
73 Changes between 03 and 04:
75 Clarified that RRSIG(0) may be defined by standards action.
77 Created a new algorithm registry and renamed the old algorithm
78 registry for SIG(0) only. Added references to the appropriate
79 crypto algorithm and format specifications.
81 Several minor rephrasings.
83 Changes between 02 and 03:
85 KEY (as well as SIG) retained for SIG(0) use only.
87 Changes between 01 and 02:
89 SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
91 Domain names embedded in NSECs and RRSIGs are not compressible and
92 are not downcased. Added unknown-rrs reference (as informative).
94 Simplified the last paragraph of section 3 (NSEC doesn't always
95 signal a negative answer).
97 Changed the suggested type code assignments.
101 Added definitions of "unsecure delegation" and "unsecure referral",
102 since they're not clearly defined elsewhere.
104 Moved 2065 to informative references, not normative.
108 The DNSSEC protocol has been through many iterations whose syntax
109 and semantics are not completely compatible. This has occurred as
110 part of the ordinary process of proposing a protocol, implementing
111 it, testing it in the increasingly complex and diverse environment
112 of the Internet, and refining the definitions of the initial
113 Proposed Standard. In the case of DNSSEC, the process has been
114 complicated by DNS's criticality and wide deployment and the need
115 to add security while minimizing daily operational complexity.
117 A weak area for previous DNS specifications has been lack of detail
118 in specifying resolver behavior, leaving implementors largely on
119 their own to determine many details of resolver function. This,
120 combined with the number of iterations the DNSSEC spec has been
121 through, has resulted in fielded code with a wide variety of
122 behaviors. This variety makes it difficult to predict how a
123 protocol change will be handled by all deployed resolvers. The
124 risk that a change will cause unacceptable or even catastrophic
125 failures makes it difficult to design and deploy a protocol change.
126 One strategy for managing that risk is to structure protocol
127 changes so that existing resolvers can completely ignore input that
128 might confuse them or trigger undesirable failure modes.
130 This document addresses a specific problem caused by Delegation
131 Signer's [DS] introduction of new semantics for the NXT RR that are
132 incompatible with the semantics in RFC 2535 [RFC2535]. Answers
133 provided by DS-aware servers can trigger an unacceptable failure
134 mode in some resolvers that implement RFC 2535, which provides a
135 great disincentive to sign zones with DS. The changes defined in
136 this document allow for the incremental deployment of DS.
140 In this document, the term "unsecure delegation" means any
141 delegation for which no DS record appears at the parent. An
142 "unsecure referral" is an answer from the parent containing an NS
143 RRset and a proof that no DS record exists for that name.
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
147 document are to be interpreted as described in [RFC2119].
151 Delegation Signer introduces new semantics for the NXT RR that are
152 incompatible with the semantics in RFC 2535. In RFC 2535, NXT
153 records were only required to be returned as part of a
154 non-existence proof. With DS, an unsecure referral returns, in
155 addition to the NS, a proof of non-existence of a DS RR in the form
156 of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
157 to interpret a response with both an NS and an NXT in the authority
158 section, RCODE=0, and AA=0. Some widely deployed 2535-aware
159 resolvers interpret any answer with an NXT as a proof of
160 non-existence of the requested record. This results in unsecure
161 delegations being invisible to 2535-aware resolvers and violates
162 the basic architectural principle that DNSSEC must do no harm --
163 the signing of zones must not prevent the resolution of unsecured
166 2. Possible Solutions
168 This section presents several solutions that were considered.
169 Section 3 describes the one selected.
171 2.1. Change SIG, KEY, and NXT type codes
173 To avoid the problem described above, legacy (RFC2535-aware)
174 resolvers need to be kept from seeing unsecure referrals that
175 include NXT records in the authority section. The simplest way to
176 do that is to change the type codes for SIG, KEY, and NXT.
178 The obvious drawback to this is that new resolvers will not be able
179 to validate zones signed with the old RRs. This problem already
180 exists, however, because of the changes made by DS, and resolvers
181 that understand the old RRs (and have compatibility issues with DS)
182 are far more prevalent than 2535-signed zones.
184 2.2. Change a subset of type codes
186 The observed problem with unsecure referrals could be addressed by
187 changing only the NXT type code or another subset of the type codes
188 that includes NXT. This has the virtue of apparent simplicity, but
189 it risks introducing new problems or not going far enough. It's
190 quite possible that more incompatibilities exist between DS and
191 earlier semantics. Legacy resolvers may also be confused by seeing
192 records they recognize (SIG and KEY) while being unable to find
193 NXTs. Although it may seem unnecessary to fix that which is not
194 obviously broken, it's far cleaner to change all of the type codes
195 at once. This will leave legacy resolvers and tools completely
196 blinded to DNSSEC -- they will see only unknown RRs.
198 2.3. Replace the DO bit
200 Another way to keep legacy resolvers from ever seeing DNSSEC
201 records with DS semantics is to have authoritative servers only
202 send that data to DS-aware resolvers. It's been proposed that
203 assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
204 called "DA"), and having authoritative servers send DNSSEC data
205 only in response to queries with the DA bit set, would accomplish
206 this. This bit would presumably supplant the DO bit described in
209 This solution is sufficient only if all 2535-aware resolvers zero
210 out EDNS0 flags that they don't understand. If one passed through
211 the DA bit unchanged, it would still see the new semantics, and it
212 would probably fail to see unsecure delegations. Since it's
213 impractical to know how every DNS implementation handles unknown
214 EDNS0 flags, this is not a universal solution. It could, though,
215 be considered in addition to changing the RR type codes.
217 2.4. Increment the EDNS version
219 Another possible solution is to increment the EDNS version number
220 as defined in RFC 2671 [RFC2671], on the assumption that all
221 existing implementations will reject higher versions than they
222 support, and retain the DO bit as the signal for DNSSEC awareness.
223 This approach has not been tested.
227 There is a large deployed base of DNS resolvers that understand
228 DNSSEC as defined by the standards track RFC 2535 and RFC 2065
229 and, due to under specification in those documents, interpret any
230 answer with an NXT as a non-existence proof. So long as that is
231 the case, zone owners will have a strong incentive to not sign any
232 zones that contain unsecure delegations, lest those delegations be
233 invisible to such a large installed base. This will dramatically
234 slow DNSSEC adoption.
236 Unfortunately, without signed zones there's no clear incentive for
237 operators of resolvers to upgrade their software to support the new
238 version of DNSSEC, as defined in [DS]. Historical data suggests
239 that resolvers are rarely upgraded, and that old nameserver code
242 Rather than wait years for resolvers to be upgraded through natural
243 processes before signing zones with unsecure delegations,
244 addressing this problem with a protocol change will immediately
245 remove the disincentive for signing zones and allow widespread
246 deployment of DNSSEC.
250 This document changes the type codes of SIG, KEY, and NXT. This
251 approach is the cleanest and safest of those discussed above,
252 largely because the behavior of resolvers that receive unknown type
253 codes is well understood. This approach has also received the most
256 To avoid operational confusion, it's also necessary to change the
257 mnemonics for these RRs. DNSKEY will be the replacement for KEY,
258 with the mnemonic indicating that these keys are not for
259 application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
260 will replace SIG, and NSEC (Next SECure) will replace NXT. These
261 new types completely replace the old types, except that SIG(0)
262 [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
264 The new types will have exactly the same syntax and semantics as
265 specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
268 1) Consistent with [RFC3597], domain names embedded in
269 RRSIG and NSEC RRs MUST NOT be compressed,
271 2) Embedded domain names in RRSIG and NSEC RRs are not downcased
272 for purposes of DNSSEC canonical form and ordering nor for
273 equality comparison, and
275 3) An RRSIG with a type-covered field of zero has undefined
276 semantics. The meaning of such a resource record may only be
277 defined by IETF Standards Action.
279 If a resolver receives the old types, it SHOULD treat them as
280 unknown RRs and SHOULD NOT assign any special meaning to them or
281 give them any special treatment. It MUST NOT use them for DNSSEC
282 validations or other DNS operational decision making. For example,
283 a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
284 validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone,
285 they MUST NOT receive special treatment. As an example, if a SIG
286 is included in a signed zone, there MUST be an RRSIG for it.
287 Authoritative servers may wish to give error messages when loading
288 zones containing SIG or NXT records (KEY records may be included
291 As a clarification to previous documents, some positive responses,
292 particularly wildcard proofs and unsecure referrals, will contain
293 NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
294 negative answers merely because they contain an NSEC.
296 4. IANA Considerations
298 4.1 DNS Resource Record Types
300 This document updates the IANA registry for DNS Resource Record
301 Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
302 DNSKEY RRs, respectively.
304 Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
305 TKEY [RFC2930] use only.
307 Type 30 (NXT) should be marked as Obsolete.
309 4.2 DNS Security Algorithm Numbers
311 To allow zone signing (DNSSEC) and transaction security mechanisms
312 (SIG(0) and TKEY) to use different sets of algorithms, the existing
313 "DNS Security Algorithm Numbers" registry is modified to include
314 the applicability of each algorithm. Specifically, two new columns
315 are added to the registry, showing whether each algorithm may be
316 used for zone signing, transaction security mechanisms, or both.
317 Only algorithms usable for zone signing may be used in DNSKEY,
318 RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG
319 may be used in SIG and KEY RRs.
321 All currently defined algorithms remain usable for transaction
322 security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private
323 algorithms (types 253 and 254) may be used for zone signing. Note
324 that the registry does not contain the requirement level of each
325 algorithm, only whether or not an algorithm may be used for the
326 given purposes. For example, RSA/MD5, while allowed for
327 transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
329 Additionally, the presentation format algorithm mnemonics from
330 RFC2535 Section 7 are added to the registry. This document assigns
331 RSA/SHA-1 the mnemonic RSASHA1.
333 As before, assignment of new algorithms in this registry requires
334 IETF Standards Action. Additionally, modification of algorithm
335 mnemonics or applicability requires IETF Standards Action.
336 Documents defining a new algorithm must address the applicability
337 of the algorithm and should assign a presentation mnemonic to the
342 Like the KEY resource record, DNSKEY contains a 16-bit flags field.
343 This document creates a new registry for the DNSKEY flags field.
345 Initially, this registry only contains an assignment for bit 7 (the
346 ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
349 4.4 DNSKEY Protocol Octet
351 Like the KEY resource record, DNSKEY contains an eight bit protocol
352 field. The only defined value for this field is 3 (DNSSEC). No
353 other values are allowed, hence no IANA registry is needed for this
356 5. Security Considerations
358 The changes introduced here do not materially affect security.
359 The implications of trying to use both new and legacy types
360 together are not well understood, and attempts to do so would
361 probably lead to unintended and dangerous results.
363 Changing type codes will leave code paths in legacy resolvers that
364 are never exercised. Unexercised code paths are a frequent source
365 of security holes, largely because those code paths do not get
368 Doing nothing, as described in section 2.5, will slow DNSSEC
369 deployment. While this does not decrease security, it also fails
372 6. Normative references
374 [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
375 RFC 2535, March 1999.
377 [DS] Gudmundsson, O., "Delegation Signer Resource Record",
378 draft-ietf-dnsext-delegation-signer-15.txt, work in
381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
382 Requirement Levels", BCP 14, RFC 2119, March 1997.
384 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
385 (SIG(0)s)", RFC 2931, September 2000.
387 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
388 RR)", RFC 2930, September 2000.
390 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
391 System (DNS)", RFC 2436, March 1999.
393 [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
394 Domain Name System (DNS)", RFC 2539, March 1999.
396 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
397 Domain Name System (DNS)", RFC 3110, May 2001.
399 7. Informative References
401 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
402 Extensions", RFC 2065, January 1997.
404 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
407 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
410 [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
411 "Domain Name System (DNS) IANA Considerations", BCP 42,
412 RFC 2929, September 2000.
414 [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
415 Resource Record (RR)", RFC 3445, December 2002.
417 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
418 Record (RR) Types", RFC 3597, September 2003.
422 The changes introduced here and the analysis of alternatives had
423 many contributors. With apologies to anyone overlooked, those
424 include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
425 Lewis, Bill Manning, and Suzanne Woolf.
427 Thanks to Jakob Schlyter and Mark Andrews for identifying the
428 incompatibility described in section 1.2.
430 In addition to the above, the author would like to thank Scott
431 Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
438 7075 Samuel Morse Drive