BIND Features

BIND is a single system that performs both authoritative and recursive DNS functions. This list of significant features is divided according to whether the feature is of more significance to one function or the other, but this is for the convenience of the reader, this is not a distinction that BIND makes.

We have started a BIND9 Significant Features matrix in our Knowledge Base that lists the major feature differences for current supported versions of BIND. 

DNS authoritative operations

An authoritative DNS server answers requests from resolvers, using information about the domain names it is authoritative for.  You can provide DNS services on the Internet by installing this software on a server and giving it information about your domain names. The BIND documentation includes a description of the Master/Slave/(stealth slave) roles for authoritative servers.


Response Rate Limiting (RRL) – An enhancement to the DNS protocol to reduce the problem of “amplification attacks” by limiting DNS responses. On by default because it has proven to be so effective.


Dynamically-Loadable Zones (DLZ) enable BIND9 to retrieve zone data directly from an external database. Not recommended for high-query rate authoritative environments.

Minimum Re-load Time

Update your BIND server zone files via nsupdate, or add ‘dynamic’ zone files via RNDC, both without restarting BIND.  For those times when you do have to restart, the ‘MAP’ zone file format can dramatically speed up re-loading a large zone file into BIND, such as on restart.

HSM Support

BIND supports the use of Hardware Security Modules through either a native PKCS#11 interface, or the OpenSSL PKCS#11 provider. HSMs are used to store key material outside of BIND for security reasons.

DNSSEC with In-line Signing

BIND fully supports DNSSEC and has a mature, full-featured easy-to use implementation. Once you have initially signed your zones, BIND can automatically resign the records as you update them with in-line signing, maintaining the DNSSEC validity of your records. BIND supports both NSEC and NSEC3 and inline signing works with NSEC3.

Catalog Zones

Catalog Zones were introduced in BIND 9.11.0 to facilitate the provisioning of zone information across a nameserver constellation.  Catalog Zones are particularly useful when there are a large number of secondary servers.

A special zone of a new type, a catalog zone, is set up on the master. Once a catalog zone is configured, when an operator wishes to add a new zone to the nameserver constellation s/he can provision the zone in one place only, on the master server and add an entry describing the zone to the catalog zone. As the secondary servers receive the updated copy of the catalog zone data they will note the new entry and automatically create a zone for it. Deletion of a zone listed in a catalog zone is done by deleting the entry in the catalog zone on the master.


Scalable Master/Slave Hierarchy

A DNS authoritative system is composed of a zone primary or master with one or more ‘slave’ servers. Zones files are established and updated on a master BIND server. Slaves maintain copies of the zone files and answer queries. This configuration allows scaling the answer capacity by adding more slaves, while zone information is maintained in only one place.

The master signals that updated information is available with a notify message to the slaves, and the slaves then initiate an update from the master. BIND fully supports both the AXFR (complete transfer) and IXFR (incremental transfer) methods, using the standard TSIG security mechanism between servers. There are a number of configuration options for controlling the zone updating process.

Recursive resolver operations

resolver is a program that resolves questions about names by sending those questions to appropriate servers and responding appropriately to the servers’ replies. In the most common application, a web browser uses a local stub resolver library on the same computer to look up names in the DNS. That stub resolver is part of the operating system. (Many operating system distributions use the BIND resolver library.) The stub resolver usually will forward queries to a caching resolver, a server or group of servers on the network dedicated to DNS services. Those resolvers will send queries to one or multiple authoritative servers in order to find the IP address for that DNS name.


When a customer searches for a non-existent domain, (NXDOMAIN response) you can redirect the user to another web page. This is done using the BIND DLZ feature.

Flexible Cache Controls

From time to time you can get incorrect or outdated records in the resolver cache.  BIND gives you the ability to remove them selectively or wholesale.

Split DNS

BIND is unique in providing the ability to configure different views in a single BIND server. This allows you to give internal (on-network) and external (from the Internet) users different views of your DNS data, keeping some DNS information private.

Optimum Cache Hit Rate

BIND is designed to be persistent and resilient in resolving queries even when there is a delay in responding, in order to populate the cache for later requests. DNS pre-fetch is a technique for continuously refreshing the cached records for popular domains, reducing the time the user has to wait for a response.

Resolver rate-limiting

Beginning with BIND 9.10.3, two new configuration parameters were added, fetches-per-zone and fetches-per-server. These features enable rate-limiting queries to authoritative systems that appear to be under attack. These features have been successful in mitigating the impact of a DDOS attack on resolvers in the path of the attack.

DNSSEC Validation

Protect your clients from imposter sites by validating DNSSEC.  In BIND, this is enabled with a single command. BIND has support for RFC 5011 maintenance of root key trust anchors. BIND also has a Negative Trust Anchor feature (introduced in the 9.9 subscription branch), which temporarily disables DNSSEC validation when there is a problem with the authoritative server’s DNSSEC support.


GeoIP, or Geographic IP, allows a BIND DNS server to provide different responses based on the network information about the recursive DNS resolver that a user is using.

There is an Internet Draft describing another mechanism for providing location information, called EDNS-Client-Subnet-Identifier. This requires the resolver to cache multiple different addresses for a given dns record, depending on the address of the requestor.  This BIND resolver was updated with this feature in the Subscriber Preview edition, with BIND 9.10.5-S. An experimental version of the corresponding feature was released for the BIND9 authoritative server in the open source in Fall 2015.


Response Policy Zone– A Response Policy Zone or RPZ is a specially-constructed zone that specifies a policy rule set. The primary application is for blocking access to zones that are believed to be published for abusive or illegal purposes.

There are companies who specialize in identifying abuse sites on the Internet, who market these lists in the form of RPZ feeds. For more information on RPZ, including a list of DNS reputation feed providers, see

Last modified: August 14, 2017 at 3:47 pm