1. Introduction

1. Introduction

1.1. Rationale

The DNS Security Extensions included the NSEC RR to provide authenticated denial of existence. Though the NSEC RR meets the requirements for authenticated denial of existence, it introduces a side-effect in that the contents of a zone can be enumerated. This property introduces undesired policy issues.

The enumeration is enabled by the set of NSEC records that exists inside a signed zone. An NSEC record lists two names that are ordered canonically, in order to show that nothing exists between the two names. The complete set of NSEC records lists all the names in a zone. It is trivial to enumerate the content of a zone by querying for names that do not exist.

An enumerated zone can be used, for example, as a source of probable e-mail addresses for spam, or as a key for multiple WHOIS queries to reveal registrant data that many registries may have legal obligations to protect. Many registries therefore prohibit the copying of their zone data; however, the use of NSEC RRs renders these policies unenforceable.

A second problem is that the cost to cryptographically secure delegations to unsigned zones is high, relative to the perceived security benefit, in two cases: large, delegation-centric zones, and zones where insecure delegations will be updated rapidly. In these cases, the costs of maintaining the NSEC RR chain may be extremely high and use of the "Opt-Out" convention may be more appropriate (for these unsecured zones).

This document presents the NSEC3 Resource Record which can be used as an alternative to NSEC to mitigate these issues.

Earlier work to address these issues include [DNSEXT-NO], [RFC4956], and [DNSEXT-NSEC2v2].

1.2. Requirements

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

1.3. Terminology

The reader is assumed to be familiar with the basic DNS and DNSSEC concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], [RFC4035], and subsequent RFCs that update them: [RFC2136], [RFC2181], and [RFC2308].

The following terminology is used throughout this document:

Zone enumeration: the practice of discovering the full content of a zone via successive queries. Zone enumeration was non-trivial prior to the introduction of DNSSEC.

Original owner name: the owner name corresponding to a hashed owner name.

Hashed owner name: the owner name created after applying the hash function to an owner name.

Hash order: the order in which hashed owner names are arranged according to their numerical value, treating the leftmost (lowest numbered) octet as the most significant octet. Note that this order is the same as the canonical DNS name order specified in [RFC4034], when the hashed owner names are in base32, encoded with an Extended Hex Alphabet [RFC4648].

Empty non-terminal: a domain name that owns no resource records, but has one or more subdomains that do.

Delegation: an NS RRSet with a name different from the current zone apex (non-zone-apex), signifying a delegation to a child zone.

Secure delegation: a name containing a delegation (NS RRSet) and a signed DS RRSet, signifying a delegation to a signed child zone.

Insecure delegation: a name containing a delegation (NS RRSet), but lacking a DS RRSet, signifying a delegation to an unsigned child zone.

Opt-Out NSEC3 resource record: an NSEC3 resource record that has the Opt-Out flag set to 1.

Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR.

Closest encloser: the longest existing ancestor of a name. See also Section 3.3.1 of [RFC4592].

Closest provable encloser: the longest ancestor of a name that can be proven to exist. Note that this is only different from the closest encloser in an Opt-Out zone.

Next closer name: the name one label longer than the closest provable encloser of a name.

Base32: the "Base 32 Encoding with Extended Hex Alphabet" as specified in [RFC4648]. Note that trailing padding characters ("=") are not used in the NSEC3 specification.

To cover: An NSEC3 RR is said to "cover" a name if the hash of the name or "next closer" name falls between the owner name and the next hashed owner name of the NSEC3. In other words, if it proves the nonexistence of the name, either directly or by proving the nonexistence of an ancestor of the name.

To match: An NSEC3 RR is said to "match" a name if the owner name of the NSEC3 RR is the same as the hashed owner name of that name.