You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

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

Scope/Audience

  • Private resolvers are not publicly accessible and cannot be reached over the open internet. They are typically found in corporate networks or other restricted-access networks. Private resolvers in some cases are 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.

Note: Enabling DoT does reduce the visibility that local administrators have into the queries being forwarded by the local recursive resolver to an upstream DoT service. However, it will still be possible to analyze queries between clients and the local DNS resolver before they are forwarded to a DoT upstream service, or by logging queries.



  • No labels