Best Practices for those running Authoritative Servers
| Author: ISC Support Reference Number: AA-00892 Views: 14108 Created: 2013-03-26 17:56 Last Updated: 2013-12-27 18:28
0 Rating/ Voters
DRAFT ARTICLE "under construction"
... your feedback is encouraged and warmly welcomed!
The following is general advice for operating solely authoritative nameservers. The items below should be considered as
starting points for determining the settings and controls most
appropriate for your environment, depending on your size, operational
needs and security concerns. They are not a complete and comprehensive
set of recommendations for all environments. There will be operational
best practices that are not specific to DNS such as BCP38, and BCP84 that you should also consider. A good business case for the deployment of BCP38 can be found here: ftp://ftp.ripe.net/ripe/docs/ripe-432.pdf. The specific DNS case is discussed in BCP 140 (RFC 5358). See also http://archive.icann.org/en/committees/security/sac004.txt.
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.
should be examined periodically for error and warning messages which
may provide a tip-off for incipient problems before they become
Review the logging configuration to ensure it meets your requirements. BIND's logging defaults are generally sane (passing most of the work to syslog), but may not line up with organizational policy
and/or desired data collection/retention standards.
using size-limited files for logging, plan the size of the files and
number to retain so that an increased level of logging due to a problem
is unlikely to cause the logs from the start of the problem to become
unavailable. The exact settings will depend on how quickly problems can
be detected and the details of the baseline retention policy.
Query logging adds substantial overhead (on the order of 10x) and so should not be turned on without careful consideration.
Prior to any trouble, ensure that a strategy is in place for collecting post-mortem information if a server does encounter a problem. This includes:
- Building named with debug symbols enabled
- Enabling the BIND XML statistics channel for easy data collection.
Designing an appropriate logging strategy and reserving sufficient
space on the log filesystem for information to be collected for a
significant context period before an event (several hours at least, 24
- Ensuring that the uid under which named is
running has write permission sufficient to write a core image to its
working directory if it segmentation faults and to write named.dump or
named.run files if requested by operator.
See What to do with a misbehaving BIND server and What to do if your BIND or DHCP server has crashed for guidance on troubleshooting problems and the type of information that is useful to collect in those circumstances.
a multi-threaded BIND build and launch named with an appropriate number
of task threads tuned for the hardware and CPU architecture.
System administrators may benefit from running tests with different values of -n (number of worker threads) and -U (from BIND 9.9 onwards - number of listening tasks per socket) to confirm the optimum tunings for their architecture and typical query profile and load. Particularly when the number of logical CPUs exceeds the number of physical CPUs, setting -n to the number of physical CPUs may improve throughput. From BIND 9.9 upwards, the number of listener tasks per interface defaults to -n, but administrators may see performance improvements, particularly reducing CPU overhead at the same time with a value of -U that lies between n-1 and n/2.
Observe query loads periodically to establish baseline expectations. This will
enable you to monitor for anything unusual - as defined by the range of
'normal' for your specific operational environment.
currently-supported version(s) of BIND in your environment.
have a strategy that includes both a planned upgrade path to ensure that
you can take advantage of improved features and functionality, as well
well as how you will respond if there is a security advisory released
that has the potential to impact your servers and services. See Which version of BIND do I want to download and install? for more information.
ISC BIND source includes a comprehensive unit test suite designed to
test correct functional performance. After using the configure script
to tailor BIND for local conditions and desired optional components, run
"make test" to verify that the build options you have selected will
produce run-time code that functions correctly in your environment.
Example for running the test suite (your configure options and choice of user privileges may not be identical):
./configure --with-openssl --enable-threads --with-libxml2
sudo bin/tests/system/ifconfig.sh up
sudo bin/tests/system/ifconfig.sh down
general advice for security practices is included in the list above.
However many large production environments with mission-critical DNS
needs may opt to run servers on multiple hardware and/or OS platforms to
increase the "eco-diversity" of their DNS infrastructure. This also
includes running different versions of BIND for resilience to potential
defects that may not impact all currently supported versions.
Per the named man page:
On Linux, named uses the kernel's
capability mechanism to drop all root privileges except the ability to
bind(2) to a privileged port and set process resource limits.
Unfortunately, this means that the -u option only works when named is
run on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later, since
previous kernels did not allow privileges to be retained after
© 2001-2017 Internet Systems ConsortiumFor assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.