Versions Compared

Old Version 13

changes.mady.by.user Steven Kim

Saved on

compared with

New Version 14

changes.mady.by.user Steven Kim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

(Private , corporate LAN, single or multi-site, serving clients and servers of this entity alone)

Scope/Audience

...

resolvers are normally found on corporate/restricted networks and are not publicly accessible

...

. They are often located on private IP address subnets (RFC1918, for instance), limiting reachability from the rest of the Internet (with or without the use of access control lists/filters). Private resolvers are in some cases part of a trusted computing domain (e.g., Active Directory).

Availability and resiliency of the DNS service

  1. MUST: Do not mix authoritative and recursive name servers on the same DNS infrastructure.
  2. MUST: Have at least one backup resolver, which clients are configured 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.
    1. 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.
  3. MUST: Enable monitoring of your services, servers, and network equipment that make up your DNS infrastructure.
  4. SHOULD: Have software diversity. The primary and backup resolvers should ideally be running software packages from different vendors.

Network security

  1. MUST: Implement BCP38/MANRS - egress filtering, so that no network traffic can leave your network with a source IP address that is not assigned to you or your customers.
  2. SHOULD: Use ACLs to restrict who can send queries to the resolvers. This might not be strictly necessary if your network is residing on an RFC1918, non-routed IP network.
  3. SHOULD: Avoid enabling stateful packet filtering / reflexive access-lists in front of a DNS server. Very active DNS servers can easily overwhelm stateful packet filters and load balancers.

Host and service security

  1. MUST: Lock down the host configuration (hardening).
    1. MUST: Uninstall/disable services and software packages that are not required for offering DNS service on the system.
    2. MUST: Only run DNS software on the systems that will be offering DNS service (i.e.: do not co-locate with web server / mail server, etc.).
    3. MUST: Enable all relevant logging channels and levels for the DNS subsystem, including suitable retention policies. Send logs to a central location for archiving, inspection and auditing.
    4. MUST: Configure the DNS service itself to only respond to queries originating from known subnets. This is to avoid probing and leaking of internal DNS information in case of misconfiguration of routing/perimeter security (ACLs).
    5. MAY: Query logging for audit purposes/incident analysis (local laws and regulations permitting).
  2. MUST: Limit user permissions and application access to system resources. File permissions and ownership restrictions must be set so that users and services not directly associated with management of the DNS subsystem have no read or write access to DNS service configuration, data files and database subsystems.
    1. MUST: System and service configuration files must be versioned, enabling detection of corruption/unauthorized changes, and making it possible to roll back changes.
    2. MAY: Consider using AppArmor or another capabilities-based security mechanism to restrict which files and resources the DNS subsystem is allowed to access on the host OS.
    3. MAY: Consider placing the DNS service and associated support services in a containerized environment.
  3. MUST: Filter access to management services.
    1. MUST: Restrict access to management IP addresses and services (e.g: SSH, web-based configuration tools).
    2. MUST: Close everything except DNS by default.
  4. MUST: Secure access to the system console using cryptographic keys, protected with a passphrase (e.g. SSH keys) or using suitable two-factor authentication (OTP generator or token-based).

DNS security and privacy

  1. MUST: Enable DNSSEC validation.
  2. MUST: Enable QNAME minimization to minimize leakage of domain names.

  3. SHOULD: Enable DoT (DNS-over-TLS), or DoH (DNS-over-HTTPS). 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.

    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.

    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.

...

There are two types of best practices for 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 systemsecurity[/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.


  1. Practice 2: ACL statements MUST be used to restrict who may send recursive queries to your DNS resolvers/validators.


Rationale: Traffic to the resolvers must be permitted only from the subnets you manage/operate. This can include corporate LANs, public segments hosting services, VPN/roaming user ranges, etc.


  1. Practice 3: QNAME minimization MUST beenabled 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.

  1. 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).

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 publicly reachable from the Internet.


  1. 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.


  1. 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).