BIND / named explained in detail
Posted: Thu Apr 23, 2026 12:24 pm
BIND / named explained in detail – what it is, how it works, and why it still matters
Anyone who works with DNS, domains, nameservers, or server administration will eventually come across BIND and the named service. For many administrators, BIND has been a core part of traditional DNS infrastructure for decades. Even with modern alternatives such as PowerDNS, Knot DNS, or NSD, BIND is still highly relevant in many environments, especially where flexibility, classic zone files, and full administrative control are important.
This post explains in detail what BIND is, what named means, how the system works, where it is used, and what its strengths and weaknesses are today.
What is BIND?
BIND stands for Berkeley Internet Name Domain. It is one of the best-known and oldest DNS server implementations in existence. BIND provides the software needed for a server to answer DNS queries, manage DNS zones, perform recursive lookups, or act as an authoritative nameserver for domains.
When people say “BIND,” they usually mean the whole software package. The actual running service is called named. This process listens for DNS requests, loads zone files, answers clients, and communicates with other DNS servers.
In short:
BIND = the DNS software package
named = the daemon or running service process
What does DNS do?
Before understanding BIND, it helps to understand DNS at a basic level. The Domain Name System is essentially the phonebook of the internet. Humans remember names like example.org, while machines communicate using IP addresses such as 203.0.113.10 or 2001:db8::10.
DNS translates names into IP addresses and can also provide many other types of information, including:
A records for IPv4
AAAA records for IPv6
MX records for mail servers
NS records for nameservers
CNAME records for aliases
TXT records for SPF, DKIM, domain verification, and more
SRV records for service discovery
PTR records for reverse DNS
BIND is one of the tools used to publish and manage this DNS data.
What exactly is named?
named is the actual DNS server process in BIND. The name historically comes from “name daemon.” This service runs in the background and performs the real DNS work:
loading DNS zones
answering DNS requests
performing recursive resolution if enabled
handling zone transfers between master and secondary servers
caching answers
supporting DNSSEC
producing logs and statistics
When BIND is installed, the service that gets started is usually named. On some Linux distributions the system service may be called bind9, but internally it is still the named daemon.
Authoritative or recursive – two important operating modes
BIND can be used in different roles.
1. Authoritative DNS server
In this role, BIND is directly responsible for certain domains. It knows the zone data from its own configuration and gives authoritative answers for that domain.
Example:
A BIND server is authoritative for example.org. It knows exactly which IP address belongs to www.example.org, which mail server handles the domain, and which NS records exist.
This is the typical role for:
domain hosting
your own nameservers
public DNS zones
internal company domains
2. Recursive resolver
In this mode, BIND does not only answer questions for local zones. It also queries other DNS servers on the internet until it finds the answer, then caches the result.
This is common for:
local network resolvers
resolvers for clients or servers
ISP caching resolvers
internal company DNS infrastructure
Important: a publicly reachable recursive resolver without restrictions is dangerous, because it can be abused for DNS amplification or unnecessary load. Recursion should only be allowed for trusted networks.
How is BIND structured?
BIND configuration normally consists of several parts.
1. Main configuration file
Often located at:
/etc/bind/named.conf
or on some systems:
/etc/named.conf
This main file usually includes other configuration files.
2. Options section
This is where global settings are defined, such as:
which IP addresses named listens on
whether recursion is allowed
where zone files are stored
forwarders
DNSSEC settings
ACLs
logging
3. Zone definitions
This is where you define which domains the server manages and where their zone files are located.
4. Zone files
These files contain the actual DNS records for a domain.
Example of a simple zone
Let us use the domain example.org. A basic zone file could look like this:
$TTL 3600
@ IN SOA ns1.example.org. admin.example.org. (
2026042301
3600
1800
1209600
3600
)
@ IN NS ns1.example.org.
@ IN NS ns2.example.org.
@ IN A 203.0.113.10
www IN A 203.0.113.10
mail IN A 203.0.113.20
@ IN MX 10 mail.example.org.
@ IN TXT "v=spf1 mx -all"
Explanation of the important parts
$TTL 3600
The default TTL here is 3600 seconds, which means one hour. Resolvers are allowed to cache answers for that amount of time.
SOA record
The SOA record is the Start of Authority and one of the most important entries in any zone. It contains:
the primary nameserver
the responsible email address
the serial number
refresh
retry
expire
negative cache TTL
The serial number is especially important. Whenever you modify a zone, you should increase it so secondary nameservers can detect the change.
NS records
These define which nameservers are authoritative for the zone.
A and AAAA records
These map hostnames to IPv4 or IPv6 addresses.
MX records
These define which mail server receives email for the domain.
TXT records
TXT is commonly used today for SPF, DKIM, DMARC, ownership verification, and other metadata.
Master and secondary with BIND
BIND is very well suited for classic DNS designs using primary/master and secondary/slave servers.
The master holds the original editable zone. The secondary fetches the zone via zone transfer from the master and provides redundancy as another authoritative nameserver.
This is important for:
high availability
load sharing
better reliability
separation of write and read systems
An example zone definition on the master:
zone "example.org" {
type master;
file "/etc/bind/zones/db.example.org";
allow-transfer { 192.0.2.53; };
};
And on the secondary:
zone "example.org" {
type slave;
file "/var/cache/bind/db.example.org";
masters { 198.51.100.10; };
};
Zone transfer: AXFR and IXFR
Secondary servers retrieve zones through zone transfers.
AXFR = full zone transfer
IXFR = incremental zone transfer, only changes
Zone transfers should always be restricted carefully so that not just any host can download complete zone contents.
Reverse DNS with BIND
In addition to normal forward zones, BIND can also serve reverse DNS. In reverse DNS, an IP address is mapped back to a hostname.
For IPv4 this uses in-addr.arpa, and for IPv6 it uses ip6.arpa.
Example of an IPv4 reverse zone:
$TTL 3600
@ IN SOA ns1.example.org. admin.example.org. (
2026042301
3600
1800
1209600
3600
)
@ IN NS ns1.example.org.
10 IN PTR server1.example.org.
20 IN PTR mail.example.org.
Reverse DNS is especially important for:
mail servers
logging
network troubleshooting
proper server identity
Useful tools around BIND
BIND includes several very useful tools.
named-checkconf
Checks the BIND configuration for syntax errors.
named-checkconf
named-checkzone
Checks a single zone file.
named-checkzone example.org /etc/bind/zones/db.example.org
rndc
With rndc, you can control named, for example reloading the configuration or checking status.
rndc reload
rndc status
rndc reconfig
dig
The most important tool for testing DNS queries.
dig example.org
dig @127.0.0.1 example.org
dig MX example.org
dig AXFR example.org @ns1.example.org
Why BIND is still popular
BIND has remained widely used for a reason.
Very flexible
BIND supports many DNS features and can be adapted for very different environments.
Standard in many infrastructures
Many administrators know BIND, many tutorials are based on it, and in traditional Unix and Linux environments it is often the reference implementation.
Good control over zones
If you want precise control with static zone files, BIND is a very powerful option.
DNSSEC support
BIND offers extensive support for DNSSEC signing, validation, and secure DNS operation.
Strong master/secondary model
Classic replication via zone transfer is mature and well understood.
Weaknesses of BIND
Despite its strengths, BIND is not always the best choice.
Complexity
BIND is powerful, but it is not always beginner-friendly. Configuration can become large and error-prone.
Historically layered design
BIND has a long history. That gives it a lot of features, but not everything feels modern or simple.
Static zone file workflow
If you prefer database backends, APIs, or web panels, PowerDNS may feel more convenient.
Security requires attention
Like any public-facing DNS service, BIND must be hardened properly, updated regularly, and configured carefully.
Important security considerations
Anyone running BIND in production should keep a few basics in mind:
allow recursion only for trusted networks
restrict zone transfers
keep the software up to date
enable useful logging
bind only to necessary interfaces
configure firewall rules for TCP and UDP port 53 correctly
keep file ownership and permissions clean
review DNSSEC if you run public authoritative zones
A common mistake is accidentally running an open resolver. Another is allowing unrestricted zone transfers.
BIND in internal networks
BIND is not only for public internet domains. It is also useful in internal networks for:
internal hostnames
split DNS
local reverse zones
forwarding to upstream resolvers
DNS caching
centralized name resolution in enterprise environments
In traditional server environments or mixed Unix/Linux infrastructures, BIND remains a strong internal DNS solution.
BIND or PowerDNS or NSD?
This question comes up often.
BIND is highly flexible and traditional, especially good for administrators who want zone files and full DNS control.
PowerDNS is often attractive when you want database backends, APIs, web interfaces, or tight integration with management portals.
NSD is very lightweight and strong as an authoritative DNS server, but less general-purpose.
Unbound is often preferred as a recursive resolver when you do not specifically need BIND for recursion.
The right choice depends heavily on the use case.
Who should still use BIND today?
BIND is still a good fit for:
running your own authoritative nameservers
traditional master/secondary DNS infrastructure
administrators who want direct control
internal DNS servers
DNSSEC environments
clean file-based zone management
It is often less ideal if you mainly want:
an easy web interface
large-scale user-managed zones via API
database-driven DNS management
a minimal authoritative-only server
Final thoughts
BIND, and especially its named daemon, is one of the most important DNS server technologies in internet history. Even though modern alternatives exist, BIND has not disappeared. On the contrary, it is still a robust, flexible, and professional solution for many DNS tasks.
If you want to understand how DNS really works, BIND teaches you a lot about zone files, authoritative nameservers, recursion, reverse DNS, TTL, SOA records, zone transfers, and DNS security. That is one reason why it remains an important tool for many administrators.
BIND may not always be the easiest route, but in many cases it is one of the cleanest and most controllable ones.
Anyone who works with DNS, domains, nameservers, or server administration will eventually come across BIND and the named service. For many administrators, BIND has been a core part of traditional DNS infrastructure for decades. Even with modern alternatives such as PowerDNS, Knot DNS, or NSD, BIND is still highly relevant in many environments, especially where flexibility, classic zone files, and full administrative control are important.
This post explains in detail what BIND is, what named means, how the system works, where it is used, and what its strengths and weaknesses are today.
What is BIND?
BIND stands for Berkeley Internet Name Domain. It is one of the best-known and oldest DNS server implementations in existence. BIND provides the software needed for a server to answer DNS queries, manage DNS zones, perform recursive lookups, or act as an authoritative nameserver for domains.
When people say “BIND,” they usually mean the whole software package. The actual running service is called named. This process listens for DNS requests, loads zone files, answers clients, and communicates with other DNS servers.
In short:
BIND = the DNS software package
named = the daemon or running service process
What does DNS do?
Before understanding BIND, it helps to understand DNS at a basic level. The Domain Name System is essentially the phonebook of the internet. Humans remember names like example.org, while machines communicate using IP addresses such as 203.0.113.10 or 2001:db8::10.
DNS translates names into IP addresses and can also provide many other types of information, including:
A records for IPv4
AAAA records for IPv6
MX records for mail servers
NS records for nameservers
CNAME records for aliases
TXT records for SPF, DKIM, domain verification, and more
SRV records for service discovery
PTR records for reverse DNS
BIND is one of the tools used to publish and manage this DNS data.
What exactly is named?
named is the actual DNS server process in BIND. The name historically comes from “name daemon.” This service runs in the background and performs the real DNS work:
loading DNS zones
answering DNS requests
performing recursive resolution if enabled
handling zone transfers between master and secondary servers
caching answers
supporting DNSSEC
producing logs and statistics
When BIND is installed, the service that gets started is usually named. On some Linux distributions the system service may be called bind9, but internally it is still the named daemon.
Authoritative or recursive – two important operating modes
BIND can be used in different roles.
1. Authoritative DNS server
In this role, BIND is directly responsible for certain domains. It knows the zone data from its own configuration and gives authoritative answers for that domain.
Example:
A BIND server is authoritative for example.org. It knows exactly which IP address belongs to www.example.org, which mail server handles the domain, and which NS records exist.
This is the typical role for:
domain hosting
your own nameservers
public DNS zones
internal company domains
2. Recursive resolver
In this mode, BIND does not only answer questions for local zones. It also queries other DNS servers on the internet until it finds the answer, then caches the result.
This is common for:
local network resolvers
resolvers for clients or servers
ISP caching resolvers
internal company DNS infrastructure
Important: a publicly reachable recursive resolver without restrictions is dangerous, because it can be abused for DNS amplification or unnecessary load. Recursion should only be allowed for trusted networks.
How is BIND structured?
BIND configuration normally consists of several parts.
1. Main configuration file
Often located at:
/etc/bind/named.conf
or on some systems:
/etc/named.conf
This main file usually includes other configuration files.
2. Options section
This is where global settings are defined, such as:
which IP addresses named listens on
whether recursion is allowed
where zone files are stored
forwarders
DNSSEC settings
ACLs
logging
3. Zone definitions
This is where you define which domains the server manages and where their zone files are located.
4. Zone files
These files contain the actual DNS records for a domain.
Example of a simple zone
Let us use the domain example.org. A basic zone file could look like this:
$TTL 3600
@ IN SOA ns1.example.org. admin.example.org. (
2026042301
3600
1800
1209600
3600
)
@ IN NS ns1.example.org.
@ IN NS ns2.example.org.
@ IN A 203.0.113.10
www IN A 203.0.113.10
mail IN A 203.0.113.20
@ IN MX 10 mail.example.org.
@ IN TXT "v=spf1 mx -all"
Explanation of the important parts
$TTL 3600
The default TTL here is 3600 seconds, which means one hour. Resolvers are allowed to cache answers for that amount of time.
SOA record
The SOA record is the Start of Authority and one of the most important entries in any zone. It contains:
the primary nameserver
the responsible email address
the serial number
refresh
retry
expire
negative cache TTL
The serial number is especially important. Whenever you modify a zone, you should increase it so secondary nameservers can detect the change.
NS records
These define which nameservers are authoritative for the zone.
A and AAAA records
These map hostnames to IPv4 or IPv6 addresses.
MX records
These define which mail server receives email for the domain.
TXT records
TXT is commonly used today for SPF, DKIM, DMARC, ownership verification, and other metadata.
Master and secondary with BIND
BIND is very well suited for classic DNS designs using primary/master and secondary/slave servers.
The master holds the original editable zone. The secondary fetches the zone via zone transfer from the master and provides redundancy as another authoritative nameserver.
This is important for:
high availability
load sharing
better reliability
separation of write and read systems
An example zone definition on the master:
zone "example.org" {
type master;
file "/etc/bind/zones/db.example.org";
allow-transfer { 192.0.2.53; };
};
And on the secondary:
zone "example.org" {
type slave;
file "/var/cache/bind/db.example.org";
masters { 198.51.100.10; };
};
Zone transfer: AXFR and IXFR
Secondary servers retrieve zones through zone transfers.
AXFR = full zone transfer
IXFR = incremental zone transfer, only changes
Zone transfers should always be restricted carefully so that not just any host can download complete zone contents.
Reverse DNS with BIND
In addition to normal forward zones, BIND can also serve reverse DNS. In reverse DNS, an IP address is mapped back to a hostname.
For IPv4 this uses in-addr.arpa, and for IPv6 it uses ip6.arpa.
Example of an IPv4 reverse zone:
$TTL 3600
@ IN SOA ns1.example.org. admin.example.org. (
2026042301
3600
1800
1209600
3600
)
@ IN NS ns1.example.org.
10 IN PTR server1.example.org.
20 IN PTR mail.example.org.
Reverse DNS is especially important for:
mail servers
logging
network troubleshooting
proper server identity
Useful tools around BIND
BIND includes several very useful tools.
named-checkconf
Checks the BIND configuration for syntax errors.
named-checkconf
named-checkzone
Checks a single zone file.
named-checkzone example.org /etc/bind/zones/db.example.org
rndc
With rndc, you can control named, for example reloading the configuration or checking status.
rndc reload
rndc status
rndc reconfig
dig
The most important tool for testing DNS queries.
dig example.org
dig @127.0.0.1 example.org
dig MX example.org
dig AXFR example.org @ns1.example.org
Why BIND is still popular
BIND has remained widely used for a reason.
Very flexible
BIND supports many DNS features and can be adapted for very different environments.
Standard in many infrastructures
Many administrators know BIND, many tutorials are based on it, and in traditional Unix and Linux environments it is often the reference implementation.
Good control over zones
If you want precise control with static zone files, BIND is a very powerful option.
DNSSEC support
BIND offers extensive support for DNSSEC signing, validation, and secure DNS operation.
Strong master/secondary model
Classic replication via zone transfer is mature and well understood.
Weaknesses of BIND
Despite its strengths, BIND is not always the best choice.
Complexity
BIND is powerful, but it is not always beginner-friendly. Configuration can become large and error-prone.
Historically layered design
BIND has a long history. That gives it a lot of features, but not everything feels modern or simple.
Static zone file workflow
If you prefer database backends, APIs, or web panels, PowerDNS may feel more convenient.
Security requires attention
Like any public-facing DNS service, BIND must be hardened properly, updated regularly, and configured carefully.
Important security considerations
Anyone running BIND in production should keep a few basics in mind:
allow recursion only for trusted networks
restrict zone transfers
keep the software up to date
enable useful logging
bind only to necessary interfaces
configure firewall rules for TCP and UDP port 53 correctly
keep file ownership and permissions clean
review DNSSEC if you run public authoritative zones
A common mistake is accidentally running an open resolver. Another is allowing unrestricted zone transfers.
BIND in internal networks
BIND is not only for public internet domains. It is also useful in internal networks for:
internal hostnames
split DNS
local reverse zones
forwarding to upstream resolvers
DNS caching
centralized name resolution in enterprise environments
In traditional server environments or mixed Unix/Linux infrastructures, BIND remains a strong internal DNS solution.
BIND or PowerDNS or NSD?
This question comes up often.
BIND is highly flexible and traditional, especially good for administrators who want zone files and full DNS control.
PowerDNS is often attractive when you want database backends, APIs, web interfaces, or tight integration with management portals.
NSD is very lightweight and strong as an authoritative DNS server, but less general-purpose.
Unbound is often preferred as a recursive resolver when you do not specifically need BIND for recursion.
The right choice depends heavily on the use case.
Who should still use BIND today?
BIND is still a good fit for:
running your own authoritative nameservers
traditional master/secondary DNS infrastructure
administrators who want direct control
internal DNS servers
DNSSEC environments
clean file-based zone management
It is often less ideal if you mainly want:
an easy web interface
large-scale user-managed zones via API
database-driven DNS management
a minimal authoritative-only server
Final thoughts
BIND, and especially its named daemon, is one of the most important DNS server technologies in internet history. Even though modern alternatives exist, BIND has not disappeared. On the contrary, it is still a robust, flexible, and professional solution for many DNS tasks.
If you want to understand how DNS really works, BIND teaches you a lot about zone files, authoritative nameservers, recursion, reverse DNS, TTL, SOA records, zone transfers, and DNS security. That is one reason why it remains an important tool for many administrators.
BIND may not always be the easiest route, but in many cases it is one of the cleanest and most controllable ones.