Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover
RFC 4986

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

• Versions
• 04

Network Working Group                                           H. Eland
Request for Comments: 4986                               Afilias Limited
Category: Informational                                         R. Mundy
                                                            SPARTA, Inc.
                                                              S. Crocker
                                                           Shinkuro Inc.
                                                         S. Krishnaswamy
                                                            SPARTA, Inc.
                                                             August 2007

  Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   Every DNS security-aware resolver must have at least one Trust Anchor
   to use as the basis for validating responses from DNS signed zones.
   For various reasons, most DNS security-aware resolvers are expected
   to have several Trust Anchors.  For some operations, manual
   monitoring and updating of Trust Anchors may be feasible, but many
   operations will require automated methods for updating Trust Anchors
   in their security-aware resolvers.  This document identifies the
   requirements that must be met by an automated DNS Trust Anchor
   rollover solution for security-aware DNS resolvers.

Eland, et al.                Informational                      [Page 1]
RFC 4986       DNSSEC Trust Anchor Rollover Requirements     August 2007

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.1.  Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.2.  No Known Intellectual Property Encumbrance  . . . . . . . . 6
     5.3.  General Applicability . . . . . . . . . . . . . . . . . . . 7
     5.4.  Support Private Networks  . . . . . . . . . . . . . . . . . 7
     5.5.  Detection of Stale Trust Anchors  . . . . . . . . . . . . . 7
     5.6.  Manual Operations Permitted . . . . . . . . . . . . . . . . 7
     5.7.  Planned and Unplanned Rollovers . . . . . . . . . . . . . . 7
     5.8.  Timeliness  . . . . . . . . . . . . . . . . . . . . . . . . 8
     5.9.  High Availability . . . . . . . . . . . . . . . . . . . . . 8
     5.10. New RR Types  . . . . . . . . . . . . . . . . . . . . . . . 8
     5.11. Support for Trust Anchor Maintenance Operations . . . . . . 8
     5.12. Recovery from Compromise  . . . . . . . . . . . . . . . . . 8
     5.13. Non-Degrading Trust . . . . . . . . . . . . . . . . . . . . 8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 9
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 9

Eland, et al.                Informational                      [Page 2]
RFC 4986       DNSSEC Trust Anchor Rollover Requirements     August 2007

1.  Introduction

   The Domain Name System Security Extensions (DNSSEC), as described in
   [2], [3], and [4], define new records and protocol modifications to
   DNS that permit security-aware resolvers to validate DNS Resource
   Records (RRs) from one or more Trust Anchors held by such security-
   aware resolvers.

   Security-aware resolvers will have to initially obtain their Trust
   Anchors in a trustworthy manner to ensure the Trust Anchors are
   correct and valid.  There are a number of ways that this initial step
   can be accomplished; however, details of this step are beyond the
   scope of this document.  Once an operator has obtained Trust Anchors,
   initially entering the Trust Anchors into their security-aware
   resolvers will in many instances be a manual operation.

   For some operational environments, manual management of Trust Anchors
   might be a viable approach.  However, many operational environments
   will require a more automated, specification-based method for
   updating and managing Trust Anchors.  This document provides a list
   of requirements that can be used to measure the effectiveness of any
   proposed automated Trust Anchor rollover mechanism in a consistent
   manner.

2.  Terminology

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

   The use of RFC 2119 words in the requirements is intended to
   unambiguously describe a requirement.  If a tradeoff is to be made