--- /dev/null
+
+INTERNET-DRAFT Sam Weiler
+Expires: August 2003 February 24, 2003
+
+
+ Legacy Resolver Compatibility for Delegation Signer
+ draft-weiler-dnsext-dnssec-2535-compat-00.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet- Drafts
+ as reference material or to cite them other than as "work in
+ progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Comments should be sent to the author or to the DNSEXT WG mailing
+ list: namedroppers@ops.ietf.org
+
+Abstract
+
+ As the DNS Security (DNSSEC) specifications have evolved, the
+ syntax and semantics of the DNSSEC resource records have changed.
+ Many deployed nameservers understand variants of these semantics.
+ To avoid dangerous interactions when a resolver that understands an
+ earlier version of these semantics queries an authoritative server
+ that understands the new delegation signer semantics, this document
+ proposes changing the type codes and mnemonics of the previous
+ DNSSEC resource records (SIG, KEY, and NXT).
+
+1. Introduction
+
+ The DNSSEC protocol has been through many iterations whose syntax
+ and semantics are not completely compatible. In particular,
+ delegation signer [DS] introduces new semantics for the NXT RR that
+ are incompatible with the semantics in [RFC2535].
+
+ In [RFC2535], NXT records were only returned as part of a
+ non-existence proof. In [DS], an unsecure referral returns, in
+ addition to the NS, an NXT and SIG(NXT) to prove the non-existence
+ of a DS RR. [RFC2535] didn't specify resolver behavior in response
+ to an answer with NOERROR or NODATA set and both an NS and an NXT
+ in the authority section.
+
+ Certain widely deployed 2535-aware resolvers interpret any answer
+ with an NXT as a non-existence proof. This results in unsecure
+ delegations being invisible to these versions of 2535-aware
+ resolvers and violates the basic architectural principle that
+ DNSSEC must do no harm -- DNSSEC must not prevent resolution of
+ unsecured names. Since it's impractical to force all recursive
+ resolvers to upgrade, zone owners who want their zones to be
+ globally reachable will have a strong incentive to not sign their
+ zones.
+
+2. Proposed Solution
+
+ To avoid the problem described above, legacy resolvers (those that
+ are 2535-aware) need to be kept from seeing unsecure referrals that
+ include NXT records in the authority section. We propose doing
+ this by changing the type codes for SIG, KEY, and NXT. To avoid
+ operational confusion, it's also necessary to change the mnemonics
+ for these RRs.
+
+ The new types will have exactly the same syntax and semantics as
+ specified for SIG, KEY, and NXT in [DNSSEC] and [DS], and they
+ completely replace the old types -- a resolver, if it receives the
+ old types, SHOULD treat them as unknown RRs, and SHOULD NOT assign
+ any special semantic value to them. It SHOULD NOT use them for
+ DNSSEC validations or other DNS operational decision making. An
+ authoritative server SHOULD NOT serve the old RR types.
+
+3. Alternative Solutions
+
+3.1 Changing only NXT
+
+ The observed problem with unsecure referrals could be addressed by
+ changing only the NXT type code. It's quite possible, however,
+ that additional incompatibilities exist between [DS] and earlier
+ semantics. It's also possible that legacy code will be confused by
+ seeing records it thinks it understands (SIG and KEY) while being
+ unable to find NXTs. Although it may seem unnecessary to fix that
+ which is not obviously broken, it's far cleaner to change all of
+ the type codes at once. This will leave legacy code (resolvers and
+ tools) completely blinded to DNSSEC -- it will see only unknown
+ RRs.
+
+3.2 Replacing the DO bit
+
+ Another way to keep legacy resolvers from ever seeing DNSSEC
+ records with [DS] semantics is to have authoritative servers only
+ send that data to DS-aware resolvers. It's been proposed that
+ assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
+ called "DA"), and having authoritative servers send DNSSEC data
+ only in response to queries with the DA bit set, would accomplish
+ this. This bit would presumably supplant the DO bit described in
+ [RFC3225].
+
+ This solution is sufficient only if all 2535-aware resolvers zero
+ out EDNS0 flags that they don't understand. If one passed through
+ the DA bit unchanged, it would still see the new semantics, and it
+ would probably fail to see unsecure delegations. Since it's
+ impractical to know how every DNS implementation handles unknown
+ EDNS0 flags, this is not a universal solution. It could, though,
+ be considered in addition to changing the RR type codes.
+
+4. IANA Considerations
+
+ This document updates the IANA registry for DNS Resource Record
+ Types by assigning types X, Y, and Z to the X, Y, and Z, RRs,
+ respectively.
+
+5. Security Considerations
+
+ The change proposed here does not materially effect security. The
+ implications of trying to use both new and legacy types together
+ are not well understood, and attempts to do so would probably lead
+ to unintended results. Accordingly, zones SHOULD NOT contain both
+ new and legacy types, and resolvers MUST NOT attempt to use both
+ new and legacy types in making trust decisions.
+
+ Changing type codes (or changing the EDNS0 flag) will leave code
+ paths in legacy resolvers that are never exercised. Unexercised
+ code paths are a frequent source of security holes, largely because
+ those code paths do not get frequent scrutiny.
+
+6. References
+
+ [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
+ Extensions", RFC 2065, January 1997.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC", RFC
+ 3225, December 2001.
+
+ [DS] Gudmundsson, O., "Delegation Signer Resource Record",
+ draft-ietf-dnsext-delegation-signer-12.txt, work in
+ progress, December 2002.
+
+ [DNSSEC] DNSSEC rewrite documents.
+
+7. Author's Address
+
+ Sam Weiler
+ Network Associates Laboratories
+ 15204 Omega Dr., Suite 300
+ Rockville, MD 20850
+ USA
+ weiler@tislabs.com
+
+
projects / thirdparty / bind9.git / commitdiff
