[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
INTERNET-DRAFT Samuel Weiler
Expires: November 2003 May 12, 2003
Legacy Resolver Compatibility for Delegation Signer
draft-weiler-dnsext-dnssec-2535-compat-01
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 (RRs) have
changed. Many deployed nameservers understand variants of these
semantics. Dangerous interactions can occur when a resolver that
understands an earlier version of these semantics queries an
authoritative server that understands the new delegation signer
semantics, including at least one failure scenario that will cause
an unsecured zone to be unresolvable. This document proposes that
these interactions be avoided by changing the type codes and
mnemonics of the DNSSEC RRs (SIG, KEY, and NXT).
1. Introduction
The DNSSEC protocol has been through many iterations whose syntax
and semantics are not completely compatible. This has occurred as
part of the ordinary process of proposing a protocol, implementing
it, testing it in the increasingly complex and diverse environment
of the Internet, and refining the definitions of the initial
Proposed Standard. In the case of DNSSEC, the process has been
complicated by DNS's criticality and wide deployment and the need
to add security while minimizing daily operational complexity.
A weak area for previous DNS specifications has been lack of detail
in specifying resolver behavior, leaving implementors largely on
their own to determine many details of resolver function. This,
combined with the number of iterations the DNSSEC spec has been
through, has resulted in fielded code with a wide variety of
behaviors. This variety makes it difficult to predict how a
protocol change will be handled by all deployed resolvers. The
risk that a change will cause unacceptable or even catastrophic
failures makes it difficult to design and deploy a protocol change.
One strategy for managing that risk is to structure protocol
changes so that existing resolvers can completely ignore input that
might confuse them or trigger undesirable failure modes.
This document addresses a specific problem caused by Delegation
Signer's [DS] introduction of new semantics for the NXT RR that are
incompatible with the semantics in [RFC2535]. Answers provided by
DS-aware servers can trigger an unacceptable failure mode in some
resolvers that implement RFC 2535, which provides a great
disincentive to sign zones with DS. The proposed solution allows
for the incremental deployment of DS.
1.1 The Problem
Delegation signer [DS] introduces new semantics for the NXT RR that
are incompatible with the semantics in [RFC2535]. In [RFC2535],
NXT records were only required to be returned as part of a
non-existence proof. In [DS], an unsecure referral returns, in
addition to the NS, a proof of non-existence of a DS RR in the form
of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
to interpret a response with both an NS and an NXT in the authority
section and with NOERROR or NODATA set. Some widely deployed
2535-aware resolvers interpret any answer with an NXT as a proof of
non-existence of the requested record. This results in unsecure
delegations being invisible to 2535-aware resolvers and violates
the basic architectural principle that DNSSEC must do no harm --
the signing of zones must not prevent the resolution of unsecured
names.
2. Possible Solutions
This section presents several possible solutions. Section 3
recommends one and describes it in more detail.
2.1. Change SIG, KEY, and NXT
To avoid the problem described above, legacy (RFC2535-aware)
resolvers need to be kept from seeing unsecure referrals that
include NXT records in the authority section. The simplest way to
do that is to change the type codes for SIG, KEY, and NXT.
The obvious drawback to this is that new resolvers will not be able
to validate zones signed with the old RRs. This problem already
exists, however, because of the changes made by DS, and resolvers
that understand the old RRs (and have compatibility issues with DS)
are far more prevalent than 2535-signed zones.
2.2. Change a subset of type codes
The observed problem with unsecure referrals could be addressed by
changing only the NXT type code or another subset of the type codes
that includes NXT. This has the virtue of apparent simplicity, but
it risks introducing new problems or not going far enough. It's
quite possible that more incompatibilities exist between DS and
earlier semantics. Legacy resolvers may also be confused by seeing
records they recognize (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 resolvers and tools completely
blinded to DNSSEC -- they will see only unknown RRs.
2.3. Replace 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.
2.4. Increment the EDNS version
Another proposed solution is to increment the EDNS version number
as defined in [RFC2671], on the assumption that all existing
implementations will reject higher versions than they support,
and retain the DO bit as the signal for DNSSEC awareness. This
approach has not been tested.
2.5. Do nothing
There is a large deployed base of DNS resolvers that understand
DNSSEC as defined by the standards track [RFC2535] and [RFC2065]
and, due to underspecification in those documents, interpret any
answer with an NXT as a non-existence proof. So long as that is
the case, zone owners will have a strong incentive to not sign any
zones that contain unsecure delegations, lest those delegations be
invisible to such a large installed base. This will dramatically
slow DNSSEC adoption.
Unfortunately, without signed zones there's no clear incentive for
operators of resolvers to upgrade their software to support the new
version of DNSSEC, as defined in [DS]. Historical data suggests
that resolvers are rarely upgraded, and that old nameserver code
never dies.
Rather than wait years for resolvers to be upgraded through natural
processes before signing zones with unsecure delegations,
addressing this problem with a protocol change will immediately
remove the disincentive for signing zones and allow widespread
deployment of DNSSEC.
3. Protocol changes
This document proposes changing the type codes of SIG, KEY, and
NXT. This solution is the cleanest and safest, largely because the
behavior of resolvers that receive unknown type codes is well
understood. This approach has also received the most testing.
To avoid operational confusion, it's also necessary to change the
mnemonics for these RRs. DNSKEY will be the replacement for KEY,
with the mnemonic indicating that these keys are not for
application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
will replace SIG, and NSEC (Next SECure) will replace NXT.
The new types will have exactly the same syntax and semantics as
specified for SIG, KEY, and NXT in [RFC2535] 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 MUST NOT use them for
DNSSEC validations or other DNS operational decision making. For
example, a resolver MUST NOT use DNSKEYs to validate SIGs or use
KEYs to validate RRSIGs. Authoritative servers SHOULD NOT serve
SIG, KEY, or NXT records. If those records are included, they MUST
NOT receive special treatment. As an example, if a SIG is included
in a signed zone, there MUST be an RRSIG for it.
As a clarification to previous documents, NSEC can appear in the
authority section of an answer at any time, not just in negative
answers. The mere presence of an NSEC record in the answer or
authority section of an answer with RCODE=NOERROR, MUST NOT be
interpreted as a negative answer. The NSEC must be validated.
4. IANA Considerations
This document updates the IANA registry for DNS Resource Record
Types by assigning types 46, 47, and 48 to the DNSKEY, RRSIG, and
NSEC RRs, respectively.
Types 24, 25, and 30 (SIG, KEY, and NXT) should be marked as
Obsolete.
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 and dangerous results.
Changing type codes 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.
Doing nothing, as described in 3.1, will slow DNSSEC deployment.
While this does not decrease security, it also fails to increase
it.
6. Normative 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.
[DS] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-14.txt, work in
progress, May 2003.
7. Informative References
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning.
Domain Name System (DNS) IANA Considerations. BCP 42,
RFC 2929, September 2000.
[RFC3445] Massey, D., and S. Rose. Limiting the Scope of the KEY
Resource Record (RR). RFC 3445, December 2002.
8. Acknowledgments
The proposed solution and the analysis of alternatives had many
contributors. With apologies to anyone overlooked, those include:
Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
Bill Manning, and Suzanne Woolf.
Thanks to Jakob Schlyter and Mark Andrews for identifying the
incompatibility described in section 1.1.
In addition to the above, the author would like to thank Scott
Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
comments.
9. Author's Address
Samuel Weiler
Network Associates Laboratories
15204 Omega Dr., Suite 300
Rockville, MD 20850
USA
weiler@tislabs.com
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/