Minimally Covering NSEC Records and DNSSEC On-line Signing
updates
Extracted elements (19)
NSEC records denying the existence of a wildcard can be pregenerated or cached, since a wildcard-denying NSEC is likely to be used in response to many queries. This optimization reduces the on-demand signing load for a common case.
NSEC records in a signed DNSSEC zone reveal zone contents via zone walking: repeated NSEC queries retrieve all instantiated names. Minimally covering NSEC records narrow the span between owner name and next name to make zone walking require approximately as many queries as brute-force enumeration, rendering it impractical.
The epsilon functions described in Section 4 are imperfect: they do not account for DNS name label count limits or total name length limits. The technique remains valid despite imperfect functions because generated NSECs must be checked against existing names regardless, and substitution is used when needed.
This technique requires on-line private keys and on-demand signing, both of which introduce security risks. At publication time, the DNSEXT WG was developing NSEC3 as an alternative that avoids on-line signing, though NSEC3 exposes slightly more zone information (e.g., the count of instantiated names).
To minimize the number of signatures that must be generated on demand, a zone may wish to limit the number of algorithms in its DNSKEY RRset, since one RRSIG per algorithm per generated NSEC is required.
Setting the 'next name' field to a name other than the next instantiated name relaxes RFC 4034 Section 4.1.1. This change is expected to be fully compatible with all existing DNSSEC validators, which do not require the next name to be an instantiated zone name.
Each generated NSEC record MUST have corresponding RRSIGs generated using each algorithm (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as described in RFC 4035 Section 2.2.
Generated NSEC records must not cover any existing names. If a generated NSEC would cover an existing name, a better epsilon function must be used or the nearest existing name must be substituted as the NSEC owner name or next name. If an existing name is used as the NSEC owner name, that name's real NSEC record MUST be returned.
The type bitmap of a dynamically generated NSEC record SHOULD NOT have any bits set other than RRSIG and NSEC.
Epsilon functions generate lexically nearby names to serve as the owner name and next name of a minimally covering NSEC. They need not be perfect or consistent, but must not produce names that cover any existing instantiated names. They are named after the mathematical convention of using epsilon for small deviations.
For instantiated names, the 'next name' field of the NSEC record is set to any name that falls lexically after the NSEC owner name and before the next instantiated name, rather than the next instantiated name itself. This relaxes the RFC 4034 Section 4.1.1 requirement and is expected to be fully compatible with existing DNSSEC validators.
Whenever an NSEC record must prove non-existence of a name (QNAME), a new NSEC record is dynamically generated and signed. Its owner name is lexically before QNAME but after any existing name, and its 'next name' is lexically after QNAME but before any existing name.
An attacker could replay an old but still validly signed NSEC record after a new name has been added within the covered span, falsely proving non-existence of that name. This danger already exists with standard DNSSEC; minimally covering NSEC records actually reduce this risk because each NSEC spans fewer names, and better epsilon functions reduce it further.
Because digital signature generation is computationally expensive, the requirement for on-demand RRSIG generation makes authoritative servers vulnerable to denial-of-service attacks that force high volumes of signing operations.
If the epsilon functions are predictable, on-demand signing may enable a chosen-plaintext attack on the zone's private keys. Zones using this technique should prefer cryptographic algorithms resistant to chosen-plaintext attacks. No zone is required to use any particular signing algorithm.
On-demand signing requires that a zone's authoritative servers have continuous access to the zone's private keys. Storing private keys on well-known Internet-accessible servers significantly increases the risk of unintended key disclosure compared to offline signing.
The effectiveness of this technique depends critically on the quality of the epsilon functions. An increment function that is obviously derived from the next instantiated name, or that always returns a name very close to the next instantiated name, can be easily reverse-engineered and defeats the purpose of zone walking prevention.
To decrement a DNS name (produce the lexically preceding name): decrement the last character of the leftmost label, then pad that label to 63 octets with bytes of value 255 (0xFF). If the last character is a null octet, remove it; if this leaves an empty label, remove the label entirely. Numerically: fill the leftmost label to 63 octets with zeros and subtract one.
To increment a DNS name (produce the lexically next name): add a leading label consisting of a single null (zero-value) octet. This prepends '\000' as the leftmost label.