These best practices cover two categories of public resolvers:

Closed and Public Resolvers – Access to this type of resolver services is determined either by the source IP address or by some other mechanism (TSIG key, TLS certificate, etc.). These service providers are typically NOT Internet Service Providers, and the clients sending the queries are located on remote networks. Note that some operators of closed and public resolvers may also offer a free tier service, which also makes them open and public resolvers (for example, commercial DNS filtering/scrubbing services).

Open and Public Resolvers –  “Fully open” public DNS resolvers are available to any users on the Internet freely to use, whether they are stub resolvers (clients) or recursive servers using the open resolver as a forwarding service.

There are two types of best practices for public resolver operators: DNS security, and DNS availability and resilience. In addition to these two categories specific to the core DNS, all operators must pay careful attention to practices related to hardening their core system security.

Practice 1

DNSSEC validation MUST be enabled for recursive resolvers.

Signing zones using DNSSEC authenticates the origin of the data and protects the data’s integrity. But for this to actually work, DNS resolvers performing recursive resolution must validate the data. This means they must be configured with a copy of the root Trust Anchor, and they must be told to validate signatures that are published alongside DNS records

Practice 2

(Privacy consideration): QNAME minimization MUST be enabled in order to mitigate leakage of domain names.

QNAME minimization (standardized in RFC 9156) is a technique to improve privacy for DNS queries. With QNAME minimization enabled, the DNS resolver doesn’t send the FQDN and query type (QTYPE) to resolvers it is querying to find the answer to a query, at the expense of a few additional queries.

Practice 3

(Privacy consideration): DoT (DNS-over-TLS) or DoH (DNS-over-HTTPS) MUST be enabled and offered to clients alongside traditional, unencrypted DNS. Deploying either DoT or DoH is the easiest way to protect against eavesdropping and manipulation of DNS queries and man-in-the-middle attacks by encrypting DNS queries between stub and recursive resolvers, or between a forwarding and recursive resolver.

In the context of public resolvers, DoT or DoH must be enabled between the resolver on the local network(s) and an external, trusted DoT/DoH-enabled forwarding resolver. This ensures that DNS queries being forwarded from local clients are encrypted between the local resolver and the external forwarder. While DoT and DoH may reduce the visibility that local administrators have into the queries being forwarded by the local recursive resolver to an upstream DoT/DoH service, it will still be possible to monitor queries between clients and the local DNS resolver, either using passive DNS analysis (if using unencrypted DNS) or query logging.

Finally, DoT and DoH do not guarantee end-to-end privacy, only protection from third-party eavesdropping between hops that use DoT/DoH: the resolver that queries are being forwarded to should also use DoT/DoH when performing resolution.

Practice 4

Authoritative and recursive DNS service MUST NOT coexist on the same DNS server.

DNS software packages such as ISC BIND can be configured to function as authoritative and recursive resolution on the same installation. Historically, this was to avoid the cost and overhead of two separate servers, particularly before virtualization was common. This is still the default behavior in most Windows DNS deployments as well. Clients in Active Directory-enabled environments are typically configured to send recursive DNS lookups to DNS servers that by default serve a copy of the organization’s DNS zone. Queries for other domain names are resolved as usual (either directly, or by forwarding queries to an external server).

While this configuration does allow for a simpler setup (and faster lookup times) when looking up names within an organization’s own domain/zone, there are other problems with this configuration, including the risk for those DNS servers answering queries for “stale” domains that have since been delegated to other nameservers. This is a risk when the DNS servers are serving public DNS zones, the contents of which can be looked up from the Internet.

Practice 5

Data collected through passive logging of DNS queries MUST only be retained for as long as is necessary for the sound operation of the service offered, including troubleshooting, research, and satisfying local legal requirements on data retention.

It is often necessary to enable logging of a service or application, including logging of data submitted by users and customers, in order to be able to troubleshoot problems and perform optimizations. Sometimes this is systematic and is enabled for forensic purposes (e.g., post mortem analysis of attacks, identifying misbehaving clients) or to be able to detect attacks as they are launched and before they can do major damage.

Either way, logging of data should be limited to the amount necessary ( in terms of both time and the depth of information being logged) to perform the tasks mentioned above, and should be disabled or reduced as soon as it is not required anymore. It is important to note here that legislation in many countries has made it mandatory to perform some level of logging of IP traffic, where providers and operators are asked to retain this data for months or even years. Operators should comply with these local data retention laws. DNS data can be leveraged to identify individual users, and great care must be taken that this data not be compromised, leaked, or otherwise accessed by unauthorized parties.

Practice 6

Your recursion services MUST have resilience by using at least two distinct servers that take diversity into consideration.

To avoid outages where clients aren’t able to resolve names, it is best to always hand out at least two diverse DNS resolvers when configuring clients, either using DHCP or any other provisioning method. Clients should be able to point to alternate resolver(s) to use in case of failure of the primary. Examples of resolver diversity include running software packages from different vendors; placing resolvers on different networks, ASes, and geographic locations; or specifying an alternate resolver hosted by another party. Solutions using a load balancer in front of multiple servers usually aren’t practical because they introduce complexity, and stateful systems risk being overwhelmed by DoS/malware-related traffic from infected clients. An acceptable alternative to configuring a secondary resolver is to deploy Anycast so that multiple resolvers respond to queries sent to a unique resolver IP address.

Practice 7

Monitoring of the services, servers, and network equipment that make up your DNS infrastructure MUST be implemented.

Monitoring of your DNS service is critical to ensure that it is available to users and customers. This can be achieved through local monitoring (hosted on premises) or a remote location, and either managed by yourself or a third party (outsourced/cloud based).