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).

. 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.

. 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.

. 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.

. 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.

. 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.

. 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.

. Author's Address

   Sam Weiler
   Network Associates Laboratories
   15204 Omega Dr., Suite 300
   Rockville, MD  20850
   USA
   weiler@tislabs.com