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