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:
The tests above are implemented in the getdns library and in a “stand-alone” tool: