ISC BIND Implementation

BIND DNS software from the Internet Systems Consortium (ISC) is among the leading reference implementations for DNS deployed worldwide and is available for free download. If you would like to contribute to ISC to assist them in continuing to make quality open source software, please visit their donations page at This section summarizes the configuration of BIND DNS for your convenience.

Recursive DNS servers traverse the DNS domain tree in order to identify the authoritative DNS server that can resolve the original query. Ultimately, an authoritative server is queried, and an answer is provided, which can be passed on to the resolver. The authoritative DNS server has the answers because it is configured with resource records that provide the specific IP address-to-name, name-to-IP address, and other resolution types. A DNS administrator must enter a resource record for each resolution he or she desires to provide. Resource records can also be entered by other sources if desired, such as from DHCP servers, which can provide a mapping of the IP address it just leased with the host name to which it was leased. This process is called dynamic DNS.

The most commonly deployed DNS server today is the Berkeley Internet Name Domain (BIND) implementation, freely available from the Internet Systems Consortium (ISC). As such the configuration details documented on this website relate to BIND, at least Other popular DNS implementations include Microsoft's DNS server, which may or may not be Active Directory integrated, NLnet Labs' Unbound (recursive) and NSD (authoritative), Power DNS, Knot DNS, tinydns aka djbdns, among others, and as well as several BIND-based implementations. Many organizations end up with a mix of DNS servers, due to decentralized administration or procurement processes, mergers and acquisitions, or organic growth. Regardless, all of these DNS server types by necessity support Internet standard DNS queries for name resolution. Methods of configuration vary however. For BIND or BIND-based configurations, one DNS server is typically denoted as master and one or more other DNS servers is denoted as a slave or secondary. While deploying two authoritative DNS servers meets the minimum redundancy requirement, most implementations feature one master and two or more slaves to avail clients of at least three authoritative servers.

The concept of a master simplifies configuration for the administrator. Instead of having to make a change or configure a parameter or resource record on all 3+ DNS servers that are authoritative for a zone, the administrator need only configure the update on the master server. The slave servers can be notified and/or they can query the master for changes at specific time intervals and obtain the updates. Slave servers can also obtain updates from other slave servers in a tiered fashion (master -> slave -> slave). In this scenario, the master is denoted the primary master, as this is the master server on which configuration changes are made. This term differentiates this primary master from the mid-tier slaves, which behave as masters for their slaves.

Microsoft Active Directory-integrated DNS supports the concept of multi-master natively. Upon updating the configuration of one of the master DNS servers, the Active Directory replication mechanism enables updating of all masters automatically. In either configuration, any of the DNS servers can be queried to obtain an authoritative answer.