The recently released BIND version 9.12 includes an implementation of RFC8198 – ‘Aggressive Use of DNSSEC-Validated Cache’.
While the purpose of this specification may not be immediately clear from its title, its intent is to improve the efficiency of the DNS protocol by allowing a DNSSEC-validating resolver to self-synthesize certain DNS responses — without referring to an authoritative server — if suitable NSEC/NSEC3[1] records already exist in the resolver’s cache.
Cutting out these additional round trips to the authoritative server improves DNS latency, reduces the amount of work done by recursive servers, and for some zones (especially the root zone), should dramatically reduce the amount of traffic sent to the authoritative servers.
To understand how this works, some knowledge of DNSSEC is required.
When an authoritative DNS server is asked for information about a domain name that doesn’t exist within a DNSSEC-signed zone, it returns an NSEC resource record (RFC4033, 4034, 4035) that references both the domain name from the zone that precedes the requested (non-existent) name and the domain name that follows it.
This NSEC record is signed and that signature is also returned in an RRSIG record. Between them, the NSEC record and RRSIG record form an authenticated denial of existence, or, in other words, a cryptographically signed assertion that the requested name does not exist.
By way of an example, here’s an extract of the response from a root server when asked for the SOA record for the non-existent domain ‘www.example.ud.’, which shows that the domain ‘uconnect.’ exists in the root zone and that the next entry in the root zone is ‘ug.’, and that therefore ‘ud.’ does not.
uconnect. 86400 IN NSEC ug. NS DS RRSIG NSEC
uconnect. 86400 IN RRSIG NSEC 8 1
86400 20180212050000 20180130040000 41824 .
{Signature appears here}
RFC8198 extends resolver behaviour to say that given this record is in the cache, then on receipt of a query for ‘www.example.uf.’ the resolver should recognize that it’s also covered by the (non-inclusive) range ‘uconnect.’ -> ‘ud.’ and therefore doesn’t exist.
The astute reader will note that while ‘uf.’ does not exist in the root zone in its own right, in theory, a wildcard record could exist such that a positive answer is required instead.
To prove that such a wildcard doesn’t exist a second NSEC record is returned too:
. 86400 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY
. 86400 IN RRSIG NSEC 8 0
86400 20180212050000 20180130040000 41824 .
{Signature appears here}
The wildcard label ‘*’ sorts between the empty label ‘.’ and ‘aaa.’, so as with the previous example, this forms the required proof.
Between them, these two NSEC records are sufficient to prove the requested name really does not exist. The resolver can then immediately generate an NXDOMAIN response, without having to make any further upstream queries.
Conversely, given a signed proof of the existence of a wildcard record and a signed proof of non-existence of the requested domain name, an RFC8198 capable resolver may synthesize positive answers according to that wildcard record.
In some cases, the NSEC records can also be used to generate a ‘NODATA’ response, where the name does exist, but it is known that a particular record type does not.
In BIND v9.12 this feature is enabled by default. If necessary it can be disabled using the ‘synth-from-dnssec’ configuration option. Counters are available in the BIND statistics channel for each of the three types of substitution that may occur (nxdomainsynth,nodatasynth and wildcardsynth).
ISC is grateful to APNIC for their sponsorship of the implementation of this feature in BIND.
1. The initial implementation in BIND only supports synthesis from NSEC records. NSEC3 support will be added in a future release.↩
Ray Bellis is a research fellow at Internet Systems Consortium (ISC).
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.