DNS Security (DNSSEC) Experiments
RFC 4955
Document | Type | RFC - Proposed Standard (July 2007; No errata) | |
---|---|---|---|
Author | David Blacka | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4955 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Mark Townsley | ||
Send notices to | (None) |
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 inShow full document text