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

   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(-> 4035prop | 4034prop | 4033prop), 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(-> 4035prop | 4034prop | 4033prop).  In RFC 2535(-> 4035prop | 4034prop | 4033prop), 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(-> 4035prop | 4034prop | 4033prop) 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.