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.
DNSSEC validation MUST be enabled for recursive resolvers.
(Privacy consideration): QNAME minimization MUST be enabled in order to mitigate leakage of domain names.
(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.
Authoritative and recursive DNS service MUST NOT coexist on the same DNS server.
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.
Your recursion services MUST have resilience by using at least two distinct servers that take diversity into consideration.
Monitoring of the services, servers, and network equipment that make up your DNS infrastructure MUST be implemented.