Network Working Group S. Weiler
Request for Comments: 3755 SPARTA, Inc.
Updates: 3658, 2535 May 2004
Category: Standards Track
Legacy Resolver Compatibility for Delegation Signer (DS)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2004). All Rights Reserved.
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 changes the type codes and mnemonics of
the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
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 specifications have
been through, has resulted in fielded code with a wide variety of
Weiler Standards Track [Page 1]RFC 3755 Legacy Resolver Compatibility for DS May 2004
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) [RFC3658] 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 changes defined in this
document allow for the incremental deployment of DS.
In this document, the term "unsecure delegation" means any delegation
for which no DS record appears at the parent. An "unsecure referral"
is an answer from the parent containing an NS RRset and a proof that
no DS record exists for that name.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. The Problem
Delegation Signer (DS) introduces new semantics for the NXT RR that
are incompatible with the semantics in RFC 2535. In RFC 2535, NXT
records were only required to be returned as part of a non-existence
proof. With 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 RCODE=0, AA=0, and both an NS and an NXT in the
authority section. 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