What is BIND? DNS server roles explained
Author: Domeny.ForSale editorial team Published
In brief: BIND (Berkeley Internet Name Domain) is open-source DNS server software, used primarily on Linux and Unix systems. It can publish domain information or look up DNS answers on behalf of users. It is useful when you need control over your DNS service, but provider-managed DNS is usually enough for a typical website.
What is BIND used for?
DNS (Domain Name System) is the domain naming system: among other things, it lets applications find the IP address associated with a name entered in a browser. It also stores other information, such as a domain’s mail servers and data used to verify services. BIND is one of the programs that run this system, not another name for DNS itself.
BIND is developed by Internet Systems Consortium (ISC). The current software line is BIND 9, and its main server process is called named. The package also includes administrative tools for tasks such as checking configuration and diagnosing DNS responses.
BIND does not store website files or replace a web server. Nor does it register domains. Its job is to provide DNS answers that allow a browser or another application to determine where to connect to the appropriate service.
Two roles: authoritative server and resolver
An authoritative server provides definitive data about the domains it is responsible for. An administrator defines this data in a DNS zone, a distinct part of the namespace. A zone can contain A and AAAA records specifying IP addresses, MX records directing email, and TXT records storing text information.
A recursive resolver looks up answers on behalf of a client. If the information it needs is not in its cache, it queries the appropriate DNS servers until it obtains a result. It can then keep the answer for the period specified by its TTL, the parameter that determines how long the answer may be cached.
BIND can perform both roles, but they have different access requirements. A public authoritative server should answer queries about the zones it serves. A company’s resolver, by contrast, should accept recursive queries only from authorized clients, such as devices on the local network or a VPN.
In public deployments, it is usually worth separating these roles. This makes it easier to apply different security rules and limits the impact of configuration errors.
How does managing a domain work in practice?
Suppose a company moves its website to a new server but keeps its email with the existing provider. If BIND serves its zone, the administrator changes the A record and, if IPv6 is used, the AAAA record too. The MX records remain unchanged because email delivery is not changing.
The update may not be visible to all users immediately. Resolvers may continue using the previous answer until its TTL expires. Before a planned migration, you can lower the TTL of the records being changed sufficiently far in advance, bearing in mind that the previous, longer value still applies to answers already cached.
BIND can also act as a primary or secondary server for a zone. The primary server is the source of the zone’s data, while the secondary retrieves a copy through a zone transfer. This is not a division into an “active” server and a “standby” server: both can answer queries normally.
Simply starting BIND will not move your domain’s DNS service to your own infrastructure. You also need the correct delegation: the name servers must be specified in the parent zone, usually through the domain registrar’s control panel.
What needs to be secured and checked?
Administering BIND involves more than editing records. The following are particularly important:
- Restricting recursion. A publicly accessible open resolver can be used to amplify DDoS attacks.
- Controlling zone transfers. Only authorized secondary servers should be allowed to retrieve copies of zones.
- Updating the software. Check ISC announcements and your distribution’s documentation for version, support and patch information.
- Keeping infrastructure available. Name servers should run in independent environments so that a single failure does not take down the entire DNS service.
BIND supports DNSSEC, a mechanism for signing DNS data and verifying its authenticity. DNSSEC does not encrypt queries or hide the names being looked up. Deploying it requires proper key management and linking the signed zone to its parent zone.
Before applying changes, you can check the configuration syntax with named-checkconf and the zone file with named-checkzone. After deployment, dig lets you check responses from individual servers. Correct syntax does not, however, guarantee correct delegation or that the service is reachable from the internet.
When should you choose BIND over a managed service?
BIND makes sense when an organization needs its own DNS infrastructure, local zones, fine-grained access control or integration with existing system administration. It is also useful for learning about DNS, as it lets you configure a zone yourself and observe the server’s responses.
For the owner of a business website or online shop, a managed service will often be simpler. The provider maintains the DNS servers and their software, while the user edits records in a control panel. This does not mean giving up your own domain or having to use the same company for your website and DNS.
Before installing BIND, clarify one thing: do you only need to change your domain’s records, or do you actually need to maintain a DNS server? If you only need to edit records, start by exploring what your current DNS control panel offers — running BIND yourself brings additional responsibility for availability, updates and security.
See also: What is Apache?
Read also
