Shared private resolver operators are typically ISPs or similar hosting service providers. They offer DNS resolution services to their customers (mobile, cable/DSL/fiber residential and commercial users, as well as hosted servers and applications). Access is usually determined by the source IP address of the client or host sending the queries. The client or host is using the ISP to access the rest of the Internet. These resolvers are normally shared between many different customers (although an ISP may decide to segment clients based on their type - home/residential DSL and fiber, mobile, commercial, etc.).
There are two types of best practices for shared private recursive 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 [Link] hardening their core system security [/Link].
DNS Security: These best practices are aimed at improving the security of your DNS service itself, helping prevent users from being served malicious data, and lowering the chances of data corruption going unnoticed.
- Practice 1: DNSSEC validation MUST be enabled for recursive resolvers.
Rationale: 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: ACL statements MUST be used to restrict who may send recursive queries to your DNS resolvers/validators.
Rationale: Traffic to the shared resolvers must be permitted only from clients from your known customer IP address ranges. |
- Practice 3 (Privacy consideration): QNAME minimization MUST be enabled to mitigate leakage of domain names.
Rationale: 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. |
DNS Availability and Resilience: These best practices aim to improve the robustness, resilience, and stability of your DNS infrastructure. Some of the recommendations can be implemented with minimal changes or additions to your infrastructure.
- Practice 4: Authoritative and recursive nameservers MUST NOT be mixed on the same DNS infrastructure.
Rationale: 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). |
- Practice 5: At least two distinct servers MUST be used for providing recursion services.
Rationale: To avoid outages where clients aren’t able to resolve names, it is best to always hand out at least two 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. 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 6: Monitoring of the services, servers, and network equipment that make up your DNS infrastructure MUST be implemented.
Rationale: 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). |
Bonus Practices: If you already have all of these practices in place, here are some additional recommended practice above and beyond the minimum KINDNS requirements.
- Practice 7 (Privacy consideration): DoT (DNS-over-TLS) or DoH (DNS-over-HTTPS) SHOULD be enabled. Deploying either 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.
Rationale: In the context of private networks, it is recommended that DoT or DoH 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 or query logging. |
- Practice 8: Private resolver operators SHOULD have software diversity. The primary and backup resolvers should ideally be running software packages from different vendors.
Rationale: In the event of a vulnerability affecting a DNS software package, there is a risk that all of one’s DNS servers could become unavailable at the same time if they all run that same software. |
