Legacy Resolver Compatibility for Delegation Signer (DS)
RFC 3755

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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 Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

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 changes the type codes and mnemonics of
   the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.

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

1.1.  Terminology

   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
   architectural principle that DNSSEC must do no harm -- the signing of
   zones must not prevent the resolution of unsecured delegations.

2.  Possible Solutions

   This section presents several solutions that were considered.
   Section 3 describes the one selected.

Weiler                      Standards Track                     [Page 2]