DNS4ALL: SIDN Labs' experimental public DNS resolver

Modern DNS resolvers

A resolver is a server that helps phones, laptops, IoT devices and other internet appliances to obtain the IP addresses of domain names via the DNS. Over the years, DNS resolvers have become more complex, and their field of application has become broader. For example, they're now involved in defending against malware and other threats, and in protecting user privacy, enabled partly by DNS extensions such as QNAME minimisation. That kind of functionality is made available by resolver operators as part of special (paid) resolver services, some of which offer extensive scope for configuration by the user (see the example in figure 1).

Figure 1: Example of the scope for configuration offered by some resolver services (in this case NextDNS resolver).

Another significant development has been the emergence of public DNS resolver services, including the Quad9, Cloudflare and Google Public DNS services. A public resolver service is open for anyone, anywhere on the internet to use. Amongst the user groups attracted by public resolver services are network operators. Outsourcing DNS resolving to a public service relieves a network operator of the technically demanding task of running the latest and greatest DNS resolver or an entire resolver infrastructure. What's more, most public resolver services are free and enable new features very quickly as technologies are developed.

Centralisation of public resolvers

The public resolver services operated by 'hyperscalers' such as Google now have millions of users, driving centralisation of the public resolver ecosystem. For example, data gathered by APNIC (see figure 2) shows that Google Public DNS serves roughly 10 per cent of internet users worldwide (orange line), while the next biggest public resolver service (Cloudflare – the purple line) has a share of 1 or 2 per cent.

Figure 2: Resolver data gathered by APNIC.

Figure 2 also shows that the phenomenon of resolver concentration involves only public resolvers. Roughly 65 per cent of users access the DNS using their ISPs' resolvers ('sameas' line). Almost another 20 per cent use resolvers in their own country but on other networks ('samecc' line): traditional resolvers accessible only for a given ISP's customers, rather than to everyone on the internet.

Drawbacks of public resolver centralisation

For several years now, DNS centralisation of the kind described has been a topic of debate within the technical community, because it diminishes the diversity of the DNS (resolver) ecosystem. Diversity of operators, software, hardware and network management methods is an important design principle of the internet, because it makes the internet more resilient to problems such as technical faults and DDoS attacks. The dominance of Google Public DNS is unhelpful in that regard, because the service implies a single operator using a single type of name server software.

Centralisation of the DNS resolver ecosystem also has drawbacks for the wider community, because it tends to involve a small number of (predominantly US) players having huge power and control within the DNS – as a consequence of gathering large volumes of DNS query data (the user as 'the product'). For those reasons, at the start of 2022, the European Commission introduced its own DNS4EU public resolver service developed by a public-private consortium.

Decentralisation of the public resolver ecosystem: DNS4ALL and RIPE BCPs

Following the launch of DNS4EU, we started our own experimental public resolver service in August 2022, because we were not convinced that the addition of another central resolver service was the best way of advancing the cause of internet decentralisation. We saw the development of a generic resolver blueprint suitable for implementation by any interested party as a better way forward. We named our 'blueprint resolver' DNS4ALL, with a wink at DNS4EU.

Then, in January 2023, the RIPE community set up the DNS Resolver Best Common Practice Task Force with the remit of making it easier for organisations to operate their own DNS resolvers, so that the DNS remains diverse and in the hands of the many. That objective is, of course, perfectly aligned with the goal of DNS4ALL. Drawing on the experience gained with DNS4ALL, SIDN Labs has therefore been an active contributor to the Task Force's development of best practices for DNSSEC, privacy and filtering configurations, for example. The Task Force's report was published on 1 May 2024, as RIPE-823.

The ICANN-supported KinDNS programme is a similar initiative, albeit with less detailed directions and guidance. There is also the European Resolver Policy, which is intended to serve the same purpose as KinDNS, but specifically for Europe.

DNS4ALL as a public resolver blueprint

DNS4ALL is intended to serve as a generic blueprint for use by anyone looking to set up a modern, distributed resolver infrastructure. We are focusing on resolvers that use BGP anycast, a technology that enables a uniform resolver service to be provided from multiple, geographically distributed servers, all with the same IP address. Using BGP anycast keeps a resolver service's response times down and enables large traffic volumes to be handled. That's achieved by routing DNS queries to the closest server in network topological terms. All the big public resolvers work that way.

DNS4ALL consists of roughly 30 front-end resolvers and 3 back-end resolvers (see figure 3). The front-ends receive inbound DNS queries from clients and direct them to the nearest back-end resolvers. If the nearest back-end resolver is unavailable or overloaded, a front-end resolver can send a query to an alternative back-end. The front-end resolvers (represented by the pins in figure 3) can also filter DNS traffic, for example by enabling rate limiting if a given front-end resolver is overloaded with client traffic. An interactive map showing all DNS4ALL's front-end resolvers is available at anycast.sidnlabs.nl.

Figure 3: Schematic depiction of the DNS4ALL architecture, showing front-end and back-end systems.

On the back-end systems (labelled 'Resolver'), we run Unbound. Meanwhile, the front-end systems running DNSdist are distributed all around the world in order to be close to their clients. The back-end systems are located in Frankfurt, Mexico City and Singapore.

The set-up enables DNS4ALL to rapidly process DNS queries from clients all around the world, because queries don't all have to be routed to the Netherlands, which would involve traversing a large portion of the internet in many cases. That's important in relation to how quickly web pages load, for example. Our DNS4ALL set-up has some similarity to Quad9, although that service uses PowerDNS and also Unbound (and very limited BIND9) as its resolver.

In concrete terms, the DNS4ALL blueprint consists of (1) the DNS Resolver Recommendations (RIPE-823) to which we contributed, (2) the DNS4ALL architecture illustrated in Figure 3, and (3) our implementation of the best common practices for DNS4ALL. For additional detail, see https://dns4all.eu.

DNS4ALL as a platform for experimentation and measurement

Our second objective is to use DNS4ALL as a vehicle for acquiring insight into current developments within the DNS resolver ecosystem, with a view to sharing our knowledge with the DNS community and with SIDN's DNS team. To that end, we carry out experiments using the latest (pre-standard) resolver features, 3 of which are considered below. In each case, we have begun by performing a few manual tests, because we still need to develop a privacy-friendly measurement system for DNS4ALL.

Discovery of Designated Resolvers (DDR) is a new mechanism that enables clients to automatically switch to an encrypted resolver (for added privacy) whenever one is available. With DNS4ALL, we observed that Apple had enabled DDR even before the relevant RFC (RFC 9462) had been published. We knew that because Apple devices that support DDR send DNS queries asking for SVCB-type records labelled '_dns.resolver.arpa'. In return, DNS4ALL sends details of 2 alternative, encrypted resolvers in its DDR response, one that supports DNS over HTTPS (DoH) and one that supports DNS over TLS (DoT):

;; ANSWER SECTION:
_dns.resolver.arpa. 300 IN SVCB 1 doh64.dns4all.eu. alpn=”h2” ipv4hint=194.0.5.64 ipv6hint=2001:678:8::64 key7=”/dns-query{?dns}”
_dns.resolver.arpa. 300 IN SVCB 1 dot64.dns4all.eu. alpn=”dot” ipv4hint=194.0.5.64 ipv6hint=2001:678:8::64

A DNS4ALL client can then automatically switch to a DNS-over-HTTPS (DoH) resolver or a DNS-over-TLS (DoT) resolver, preventing third-party eavesdropping on the query-response interchange between resolver and user. An even newer secure transport technology is now available for resolvers, namely DNS over QUIC. With DNSdist supporting the technology since release 1.9.0, we plan to enable DNS over QUIC on DNS4ALL in the near future.

Extended DNS Errors (EDE) is another relatively recent extension to the DNS protocol, which we have enabled on DNS4ALL. EDE enables additional information to be included in a DNS response if an error has occurred. If, for example, DNSSEC validation fails, the reason can be given in the response. For DNS4ALL clients, enabling EDE has the advantage of making it possible to quickly diagnose problems. As you can see from the specimen response, DNS4ALL also supports DNS64, which by no means all resolvers do.

X25519Kyber768 algorithm: we have even gone a step further and enabled X25519Kyber768 support on DNS4ALL, as explained in a previous blog. X25519Kyber768 is a post-quantum cryptographic algorithm, meaning that it's resistant to cracking by the extremely powerful quantum computers of the future.

Lessons learnt

The hands-on experience gained with DNS4ALL has provided us with insight into the challenges associated with keeping a large public resolver service up and running. The resulting knowledge and experience have been used to develop a blueprint suitable for use by anyone looking to help maintain the decentralised status of the DNS by setting up a modern, distributed resolver service. DNS4ALL has also enabled us to contribute to the RIPE DNS Resolver BCP Task Force, whose work has since yielded RIPE-823.

We have also learnt that successful management of a resolver like DNS4ALL often comes down to attention to detail. For example, how straightforward is it for a DNS-over-HTTPS service to provide a certificate which states both the host name and the IP address? We plan to share the answers to such questions and details of the other lessons we have learnt in the future via the DNS4ALL site at dns4all.eu.

Join DNS4ALL!

Additional information about DNS4ALL is available from https://dns4all.eu, including advice on configuring your system to use DNS4ALL and checking that your configuration works. Naturally, details of our privacy policy are also provided on the site.

Why not give DNS4ALL a try? And please do let us have your feedback!

Please note:

DNS4ALL is an experimental resolver. We do not make any service guarantees or provide support.