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