DNS Security Extension Clarification on Zone Status
RFC 3090

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

• Versions
• 05

Network Working Group                                           E. Lewis
Request for Comments: 3090                                      NAI Labs
Category: Standards Track                                     March 2001

          DNS Security Extension Clarification on Zone Status

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 (2001).  All Rights Reserved.

Abstract

   The definition of a secured zone is presented, clarifying and
   updating sections of RFC 2535.  RFC 2535 defines a zone to be secured
   based on a per algorithm basis, e.g., a zone can be secured with RSA
   keys, and not secured with DSA keys.  This document changes this to
   define a zone to be secured or not secured regardless of the key
   algorithm used (or not used).  To further simplify the determination
   of a zone's status, "experimentally secure" status is deprecated.

1 Introduction

   Whether a DNS zone is "secured" or not is a question asked in at
   least four contexts.  A zone administrator asks the question when
   configuring a zone to use DNSSEC.  A dynamic update server asks the
   question when an update request arrives, which may require DNSSEC
   processing.  A delegating zone asks the question of a child zone when
   the parent enters data indicating the status the child.  A resolver
   asks the question upon receipt of data belonging to the zone.

1.1 When a Zone's Status is Important

   A zone administrator needs to be able to determine what steps are
   needed to make the zone as secure as it can be.  Realizing that due
   to the distributed nature of DNS and its administration, any single
   zone is at the mercy of other zones when it comes to the appearance
   of security.  This document will define what makes a zone qualify as
   secure.

Lewis                       Standards Track                     [Page 1]
RFC 3090         DNS Security Extension on Zone Status        March 2001

   A name server performing dynamic updates needs to know whether a zone
   being updated is to have signatures added to the updated data, NXT
   records applied, and other required processing.  In this case, it is
   conceivable that the name server is configured with the knowledge,
   but being able to determine the status of a zone by examining the
   data is a desirable alternative to configuration parameters.

   A delegating zone is required to indicate whether a child zone is
   secured.  The reason for this requirement lies in the way in which a
   resolver makes its own determination about a zone (next paragraph).
   To shorten a long story, a parent needs to know whether a child
   should be considered secured.  This is a two part question.  Under
   what circumstances does a parent consider a child zone to be secure,
   and how does a parent know if the child conforms?

   A resolver needs to know if a zone is secured when the resolver is
   processing data from the zone.  Ultimately, a resolver needs to know
   whether or not to expect a usable signature covering the data.  How
   this determination is done is out of the scope of this document,
   except that, in some cases, the resolver will need to contact the
   parent of the zone to see if the parent states that the child is
   secured.

1.2 Islands of Security

   The goal of DNSSEC is to have each zone secured, from the root zone
   and the top-level domains down the hierarchy to the leaf zones.
   Transitioning from an unsecured DNS, as we have now, to a fully
   secured - or "as much as will be secured" - tree will take some time.
   During this time, DNSSEC will be applied in various locations in the
   tree, not necessarily "top down."

   For example, at a particular instant, the root zone and the "test."
   TLD might be secured, but region1.test. might not be.  (For
   reference, let's assume that region2.test. is secured.)  However,
   subarea1.region1.test. may have gone through the process of becoming
   secured, along with its delegations.  The dilemma here is that
   subarea1 cannot get its zone keys properly signed as its parent zone,
   region1, is not secured.

   The colloquial phrase describing the collection of contiguous secured
   zones at or below subarea1.region1.test. is an "island of security."
   The only way in which a DNSSEC resolver will come to trust any data
   from this island is if the resolver is pre-configured with the zone
   key(s) for subarea1.region1.test., i.e., the root of the island of
   security.  Other resolvers (not so configured) will recognize this
   island as unsecured.

Lewis                       Standards Track                     [Page 2]