Table of Contents

DNS Resolver Capabilities


DNS resolvers expose a wide variety of capabilities to their clients (i.e., hosts/applications using the DNS resolver). Typically, resolvers present highly diverse sets of support in UDP, TCP, ENDS0, DNSSEC, etc., while this variety can have many root causes. Obviously, different DNS resolvers do support different sets of capabilities, but in many cases the network components (CPEs, DNS proxies, firewalls, middle boxes, …) between the client and the resolver also determine which capabilities are available.

For the successful deployment of DNSSEC, validating resolvers need to obtain the DNSSEC data required for the validation process. Detecting potential problems posed by the network components and mitigation techniques can improve the uptake of DNSSEC and technologies based upon DNSSEC such as DANE.

For the hackathon, DNS Resolver Capabilities aims to develop a method and implement code to show how a host validator can detect the capabilities of a nearby recursive resolver. The results of this detection process can help the host validator to work around problems that could potentially affect DNSSEC resolution. The final goal of this work is to present and visualise DNS Resolver Capabilities, and with that to do the necessary groundwork to enable a host validator to make optimal use caching recursive resolvers to obtain DNSSEC data.


Perform measurements, active and passive, to probe the capabilities of DNS resolvers and present the results in a visual informative way.

A typical architecture of a DNS infrastructure and how DNS queries are resolved is shown below.

We designed a “intelligent test” for DNS resolver to give people a decent idea if a resolvers offered are behaving “properly”. The goal is give preference to good DNSSEC validators. For that reason all queries are issued with EDNS0 and DO bit set.

We have only 4 tests in our test set:

The success of the individual tests add up to a total score, as explained below:

  1. The first question is to check if the resolver responds and check if AD bit is set. The reason this question is issued is that it a validator is a modern one that understands NSEC3. A validator that does not support NSEC3 is not that useful today.
    • Grading: If the answer returns the resolver is granted one point and if the AD bit is set the resolver gets a bonus point
  2. The second question is to check if the resolver “lies” for A queries i.e. forges answer. The question is asked for a signed zone thus a validating application/end-system will not believe the answer as it should be impossibe to forge the answer.
    • Grading: If the server returns NXDOMAIN it gets a point and if the server has AD bit set it gets a bonus point
  3. The third question is for algorithm 13 ECDSAP256 support “ SOA ” what this test is if the resolver is up-to-date for the latest defined algorithms.
    • Grading: If this is returned the resolver gets a point if the AD bit is set a bonus point is added
  4. The final question is only asked if first or thrid question returned AD bit it is to check if validating resovler actually suppresses answers when signature is invalid “ SOA”
    • Grading: If answer has SERVFAIL the resolver gets a point bonus point if there is no AD the answer.

Code Repository

The tests above are implemented in the getdns library and in a “stand-alone” tool: