BIND Best Practices - Recursive Servers


#1
  • It is strongly recommended that you run BIND on a server dedicated to DNS only. Reasons include:

    • Minimized risk of impact to DNS services as a result of other applications consuming server resources (perhaps due to an attack on those services, or due to application error).

    • Conversely, minimized risk to other applications as a result of BIND consuming all system or network resources.

    • Reduced likelihood of unauthorized access to the DNS server (e.g. via a code defect and root access exploit made possible via another application).

    • Improved ability to monitor DNS server performance (since the server is dedicated to one service).

    • Improved ability to troubleshoot problems.

  • Run BIND as an unprivileged user.

    To open low-numbered UDP and TCP ports BIND must be launched as root, but an alternate uid can be specified using the -u command line argument; after opening needed resources named will change its runtime uid to an unprivileged account.

  • Do not operate an open resolver, open resolvers will be discovered and co-opted for use in DNS reflection attacks against third parties. Make use of BIND access control mechanisms such as address match lists to restrict recursive query service to known and authorized clients.

  • Ensure that you have query port randomization enabled. A useful testing tool provided by the Domain Name System Operations Analysis and Research Center can be found here: https://www.dns-oarc.net/oarc/services/porttest

  • Configure your recursive servers to use DNSSEC validation. DNSSEC-validation will prevent cache-poisoning of records that are provided by DNSSEC-signed authoritative zones.

  • Ensure (and confirm through testing) that your infrastructure supports EDNS0 and large UDP packet sizes. See How to verify a clean network path for DNS resolution by recursive servers

  • Do not combine authoritative and recursive name server functions on the same server – have each function performed by separate server sets.

    This advice primarily concerns separation of public-facing authoritative services from internal client-facing recursive services - administrators may, for convenience, choose to serve some internal-only zones authoritatively from their recursive servers, having determined that the benefit outweighs any risks associated with this policy.

    If you do share recursive and authoritative functions in the one server - then if there is a problem that impacts authoritative servers only - for example, that causes all of your self-authoritative servers to fail, then it will at the same time break your recursive service too.

  • Run multiple, distributed recursing resolvers, avoiding single points of failure in critical resource paths. A variety of strategies are available (including anycast and load-balancing) to ensure robust geographic and network diversity in your deployment. Those for whom high availability of DNS service is particularly critical may also wish to consider diversity of nameserver software versions and code base (e.g. running at least two different major versions of BIND on their servers, as well as DNS server software from other vendors) See Which version of BIND do I want to download and install? for further discussion of this.

  • Provision sufficient capacity to handle burst traffic up to at least 150% of normal level ( see also the above point on load-balanced configurations - adequate overprovisioning will help to avoid some of the pitfalls ).

    Remember that excess capacity must take into account not only server CPU and memory resources but also send and receive capacity along the entire network path

  • Disable the use of stateful firewalls/packet filters on your servers for outbound query traffic (iterative queries made by a recursive server to authoritative Internet servers). Administrators often consider the impact of stateful firewalls and load balancers on inbound client queries, but then fail to consider their impact on resolver query traffic.

  • Ensure that system outbound network buffers are large enough to handle your rates of outbound query traffic. Some OS implementations (linux particularly some versions) by default assume low rates of outbound network traffic - but a recursive DNS server will have significant volumes of outbound traffic, both in responding to client queries, and in handling iteration on cache-misses.

  • By design, and for security purposes, the most common mode of failure for BIND is intentional process termination when it encounters an inconsistent state. An automated minder process capable of restarting BIND intelligently is recommended if you do not have 24-hour operations support (and possibly even if you do.) It is especially helpful if any such script can checkpoint and archive the logs when this happens.

  • In general BIND sets reasonable default limits on most options, but the default value for cache size is “unlimited.” Set an appropriate limit on max-cache-size to avoid growth without limit (the maximum configurable value is (currently) 2 ^ 32 - 1 bytes, but it is possibly to configure named to run without a limit on cache size, in which case its use can exceed 4Gb). Additionally, provision enough system memory to allow storage of other BIND structures in addition to the resolver cache.

  • Run currently-supported version(s) of BIND in your environment.