DNS Security (DNSSEC) Experiments
RFC 4955

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

• Versions
• 04

Network Working Group                                          D. Blacka
Request for Comments: 4955                                VeriSign, Inc.
Category: Standards Track                                      July 2007

                   DNS Security (DNSSEC) Experiments

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 IETF Trust (2007).

Abstract

   This document describes a methodology for deploying alternate, non-
   backwards-compatible, DNS Security (DNSSEC) methodologies in an
   experimental fashion without disrupting the deployment of standard
   DNSSEC.

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
   3.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   4.  Method  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Defining an Experiment  . . . . . . . . . . . . . . . . . . . . 4
   6.  Considerations  . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Use in Non-Experiments  . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

Blacka                      Standards Track                     [Page 1]
RFC 4955           DNS Security (DNSSEC) Experiments           July 2007

1.  Overview

   Historically, experimentation with DNSSEC alternatives has been a
   problematic endeavor.  There has typically been a desire to both
   introduce non-backwards-compatible changes to DNSSEC and to try these
   changes on real zones in the public DNS.  This creates a problem when
   the change to DNSSEC would make all or part of the zone using those
   changes appear bogus (bad) or otherwise broken to existing security-
   aware resolvers.

   This document describes a standard methodology for setting up DNSSEC
   experiments.  This methodology addresses the issue of coexistence
   with standard DNSSEC and DNS by using unknown algorithm identifiers
   to hide the experimental DNSSEC protocol modifications from standard
   security-aware resolvers.

2.  Definitions and Terminology

   Throughout this document, familiarity with the DNS system (RFC 1035
   [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and
   RFC 4035 [4]) is assumed.

   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 RFC 2119 [1].

3.  Experiments

   When discussing DNSSEC experiments, it is necessary to classify these
   experiments into two broad categories:

   Backwards-Compatible:  describes experimental changes that, while not
      strictly adhering to the DNSSEC standard, are nonetheless
      interoperable with clients and servers that do implement the
      DNSSEC standard.

   Non-Backwards-Compatible:  describes experiments that would cause a
      standard security-aware resolver to (incorrectly) determine that
      all or part of a zone is bogus, or to otherwise not interoperate
      with standard DNSSEC clients and servers.

   Not included in these terms are experiments with the core DNS
   protocol itself.

   The methodology described in this document is not necessary for
   backwards-compatible experiments, although it certainly may be used
   if desired.

Blacka                      Standards Track                     [Page 2]
RFC 4955           DNS Security (DNSSEC) Experiments           July 2007

4.  Method

   The core of the methodology is the use of strictly unknown algorithm
   identifiers when signing the experimental zone, and more importantly,
   having only unknown algorithm identifiers in the DS records for the
   delegation to the zone at the parent.

   This technique works because of the way DNSSEC-compliant validators
   are expected to work in the presence of a DS set with only unknown
   algorithm identifiers.  From RFC 4035 [4], Section 5.2:

      If the validator does not support any of the algorithms listed in
      an authenticated DS RRset, then the resolver has no supported
      authentication path leading from the parent to the child.  The
      resolver should treat this case as it would the case of an
      authenticated NSEC RRset proving that no DS RRset exists, as
      described above.

   And further:

      If the resolver does not support any of the algorithms listed in