Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover
RFC 4986
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
Show full document text