Minimally Covering NSEC Records and DNSSEC On-line Signing
RFC 4470
Network Working Group S. Weiler
Request for Comments: 4470 SPARTA, Inc.
Updates: 4035, 4034 J. Ihren
Category: Standards Track Autonomica AB
April 2006
Minimally Covering NSEC Records and DNSSEC On-line Signing
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 (2006).
Abstract
This document describes how to construct DNSSEC NSEC resource records
that cover a smaller range of names than called for by RFC 4034. By
generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents
otherwise made possible by walking the chain of NSEC records in a
signed zone.
Table of Contents
1. Introduction ....................................................1
2. Applicability of This Technique .................................2
3. Minimally Covering NSEC Records .................................2
4. Better Epsilon Functions ........................................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................6
7. Normative References ............................................6
1. Introduction
With DNSSEC [1], an NSEC record lists the next instantiated name in
its zone, proving that no names exist in the "span" between the
NSEC's owner name and the name in the "next name" field. In this
document, an NSEC record is said to "cover" the names between its
owner name and next name.
Weiler & Ihren Standards Track [Page 1]
RFC 4470 NSEC Epsilon April 2006
Through repeated queries that return NSEC records, it is possible to
retrieve all of the names in the zone, a process commonly called
"walking" the zone. Some zone owners have policies forbidding zone
transfers by arbitrary clients; this side effect of the NSEC
architecture subverts those policies.
This document presents a way to prevent zone walking by constructing
NSEC records that cover fewer names. These records can make zone
walking take approximately as many queries as simply asking for all
possible names in a zone, making zone walking impractical. Some of
these records must be created and signed on demand, which requires
on-line private keys. Anyone contemplating use of this technique is
strongly encouraged to review the discussion of the risks of on-line
signing in Section 5.
1.2. Keywords
The keywords "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 [4].
2. Applicability of This Technique
The technique presented here may be useful to a zone owner that wants
to use DNSSEC, is concerned about exposure of its zone contents via
zone walking, and is willing to bear the costs of on-line signing.
As discussed in Section 5, on-line signing has several security
risks, including an increased likelihood of private keys being
disclosed and an increased risk of denial of service attack. Anyone
contemplating use of this technique is strongly encouraged to review
the discussion of the risks of on-line signing in Section 5.
Furthermore, at the time this document was published, the DNSEXT
working group was actively working on a mechanism to prevent zone
walking that does not require on-line signing (tentatively called
NSEC3). The new mechanism is likely to expose slightly more
information about the zone than this technique (e.g., the number of
instantiated names), but it may be preferable to this technique.
3. Minimally Covering NSEC Records
This mechanism involves changes to NSEC records for instantiated
names, which can still be generated and signed in advance, as well as
the on-demand generation and signing of new NSEC records whenever a
name must be proven not to exist.
Weiler & Ihren Standards Track [Page 2]
RFC 4470 NSEC Epsilon April 2006
In the "next name" field of instantiated names' NSEC records, rather
than list the next instantiated name in the zone, list any name that
falls lexically after the NSEC's owner name and before the next
instantiated name in the zone, according to the ordering function in
Show full document text