Aggressive use of NSEC

The Domain Name System (DNS) mainly converts easily remembered names (“www.example.com“) into IP addresses (“192.0.2.2“). In order to improve performance and to allow the DNS to scale, the DNS relies heavily on caching.

Unfortunately, humans (often) make mistakes, and so the DNS also has to implement “negative” caching. This is a cache that records the fact that a name does not exist. This could occur, for instance, because the domain expired or because the person entering it made a typo.

Unfortunately, the (current) negative cache requires an exact match – this means that if there is an entry for invalid1.example.com, a query for invalid2.example.com will cause the resolver to go off and try to look this up; the same thing will happen for invalid3.example.com, invalid4.example.com, etc.

Domain Name System Security Extensions (DNSSEC) adds security to the DNS by cryptographically signing answers [RFC4034, RFC4035]. This provides protection against tampering with answers by attackers, for example, to return an IP under the attacker’s control instead of the “real” answer for example.com. As well as providing cryptographic protection for names which do exist, DNSSEC also provides proof of which names do not exist.

Instead of signing every possible name in a domain that does not exist, DNSSEC accomplishes this with a clever trick – it alphabetically sorts all names in a domain and then adds signed NSEC (short for “Next Secure”) records, which states that nothing exists in the spaces between the names that do exist.

So, if example.com contains (note: there is a fair bit of simplification here – please read the RFCs for actual detail):

banana A 192.0.2.10
mail       A 192.0.2.1
www      A 192.0.2.2

DNSSEC would insert:
banana  NSEC mail
mail        NSEC www

and include signatures over these records. These say that there are no records in the range between “banana” and “mail”; and nothing between “mail” and “www”.

This means that if someone queries for server.example.com they would get back the “mail NSEC www” record, and would be able to know for certain that the name server.example.com really does not exist.

There is now a document [html, pdf] in the IETF DNSOP working group that recommends using these NSEC records in a more “aggressive” manner – it states that (DNSSEC validating) resolvers should use the information received in NSEC records, and should suppress queries for names that fall within the ranges in the NSEC records. In our very first example, if the invalid1.example.com response had included an NSEC record stating that nothing exists in the range “banana” to “mail”, it would be able to immediately return a negative answer (NXDOMAIN) to the client, and would not even have to go off and bother the example.com nameservers again.

This technique will be effective at all levels of the DNS hierarchy, but one of the largest wins is likely to be at the root of the DNS tree, where upwards of 65% of all DNS queries result in an NXDOMAIN response.

Warren Kumari is a Senior Network Security Engineer at Google.

Rate this article

---

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.