BIND 9 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 rather than a distinction in BIND 9.
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 9 documentation includes a description of the Master/Slave/(stealth slave) roles for authoritative servers.
Response Rate Limiting (RRL) – An enhancement to named to reduce the problem of “amplification attacks” by rate-limiting DNS responses. On by default because it has proven to be so effective.
Dynamically-Loadable Zones (DLZ) enable BIND 9 to retrieve zone data directly from an external database. Not recommended for high-query rate authoritative environments.
Minimum Re-load Time
Update your BIND 9 server zone files via nsupdate, or add ‘dynamic’ zone files via rndc, both without restarting BIND 9. 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 9, such as on restart.
BIND 9 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 9 for security reasons.
DNSSEC with In-line Signing
BIND 9 fully supports DNSSEC and has a mature, full-featured, easy-to-use implementation. Once you have initially signed your zones, BIND 9 can automatically re-sign dynamically updated records with inline signing. BIND 9 supports both NSEC and NSEC3, and inline signing works with NSEC and NSEC3.
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 is 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 primary master with one or more ‘slave’ servers. Zones files are established and updated on a master BIND 9 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 a zone transfer from the master. BIND 9 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
A 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 9 DLZ feature.
Flexible Cache Controls
From time to time you can get incorrect or outdated records in the resolver cache. BIND 9 gives you the ability to remove them selectively or wholesale.
BIND 9 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 9 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 prefetch is a technique for continuously refreshing the cached records for popular domains, reducing the time the user has to wait for a response. Another technique, Serve Stale, enables a resolver operator to choose to continue serving expired records, if the authority is unable to respond due to DDoS.
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.
Protect your clients from imposter sites by validating DNSSEC. In BIND 9, this is enabled with a single command. BIND 9 has support for RFC 5011 maintenance of root key trust anchors. BIND 9 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 9 DNS server to provide different responses based on the network information about the recursive DNS resolver.
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. The BIND 9 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 BIND 9 authoritative server in the open source in fall 2015.
Response Policy Zones – 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 domains 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 https://dnsrpz.info.