The Domain Name System (DNS) is the internet's "phonebook," or a hierarchical, globally distributed system that translates human-readable domain names (like www.example.com) into machine-readable Internet Protocol (IP) addresses (like 192.0.2.1).
Why DNS is Used
The primary use of DNS is to allow users to access websites and other internet resources using easy-to-remember domain names instead of having to memorize long, complex numerical IP addresses.
Simplifies Navigation: Humans find names easier to recall than strings of numbers.
Enables Flexible Hosting: A website's IP address can change, but its domain name remains the same. DNS handles the update, ensuring traffic still reaches the correct server.
Load Balancing and Fault Tolerance: DNS can be configured to direct traffic for a single domain name to multiple different IP addresses, distributing the load and ensuring a site remains available if one server fails.
How DNS Works: The Resolution Process
When you type a domain name into your browser, a process called DNS resolution happens, typically in milliseconds, involving several types of servers:
Local Cache Check: Your computer (or local network equipment) first checks its own cache to see if it already knows the IP address for the domain.
Query to DNS Resolver: If not found locally, the request goes to a Recursive DNS Resolver (usually managed by your Internet Service Provider, or a public service like Google DNS). The resolver's job is to find the final answer.
Root Server Query: The resolver queries a Root Name Server (the top of the DNS hierarchy), which responds by directing the resolver to the correct TLD Name Server (e.g., the server for .com, .org, etc.).
TLD Server Query: The resolver queries the appropriate TLD Name Server, which in turn directs the resolver to the domain's Authoritative Name Server.
Authoritative Server Query: The resolver queries the Authoritative Name Server, which holds the official DNS records for that specific domain (e.g., example.com). This server finally provides the corresponding IP address.
Response and Connection: The resolver sends the IP address back to your browser, which then uses the IP address to connect to the website's server and load the webpage.
📝 The BIND DNS Server: The Power Behind Domain Resolution
The Berkeley Internet Name Domain (BIND) software is the most widely used DNS server on the internet. The primary daemon (server process) for BIND is named (pronounced "name-dee"), which stands for Name Daemon.
The named Daemon and Core Configuration
The named daemon's job is to listen on port 53 (both UDP and TCP) for DNS queries and respond to them. It loads its configuration from the main file, typically /etc/named.conf (or sometimes a similar file like /etc/bind/named.conf or a collection of files included by the main one).
Key Components of named.conf
options { ... }; Block :
This section contains global server settings, acting as a set of defaults for all zones unless overridden.
listen-on port 53 { IP_ADDRESS; }; : Specifies which local IP addresses the server should listen on for incoming queries. By default, it might listen on all interfaces.
directory "/var/named"; : Defines the working directory where the daemon looks for zone files (if a relative path is used in the zone definition).
allow-query { any; }; : Controls which hosts are permitted to query the DNS server. any means all, while you'd typically restrict this to your internal network for caching servers.
forwarders { IP_of_External_DNS_1; IP_of_External_DNS_2; }; : If the server can't resolve a query from its local zones, it forwards the request to these external DNS servers (like Google's 8.8.8.8) instead of performing a root-to-TLD iterative query.
zone "domainname" IN { ... }; Block :
Each zone block defines a specific DNS zone for which the server is authoritative.
type master; : Designates this server as the Primary (Master) server, holding the original, editable copy of the zone file.
type slave; : Designates this server as a Secondary (Slave) server, which obtains its zone data from a master server via a Zone Transfer.
file "forward.zone"; : Specifies the location (relative to the directory option or an absolute path) of the zone file containing the actual resource records.
allow-transfer { IP_of_Slave_Server; }; : Crucial for master servers—it explicitly lists the IP addresses of slave servers permitted to transfer the zone data.
Resource Records (RRs) in Zone Files
Zone files (/var/named/forward.zone, etc.) contain the actual mappings and metadata. Each record has a standard format: [name] [TTL] [class] [type] [data].
Essential DNS Record Types
| Record Type | Description | Example |
|---|---|---|
| SOA (Start of Authority) | Required first record in every zone file. Defines the zone's administrator, serial number, and various timers (Refresh, Retry, Expire, TTL). | @ IN SOA ns1.example.com. admin.example.com. (...) |
| NS (Name Server) | Specifies the authoritative name servers for the domain. | @ IN NS ns1.example.com. |
| A (Address) | Maps a hostname to an IPv4 address (Forward Lookup). | web IN A 192.168.1.10 |
| AAAA (Quad-A Address) | Maps a hostname to an IPv6 address. | web IN AAAA 2001:db8::1 |
| PTR (Pointer) | Maps an IP address to a hostname (Reverse Lookup). Used in reverse zone files. | 10 IN PTR web.example.com. |
| MX (Mail Exchanger) | Specifies the mail server(s) for the domain and their preference. | @ IN MX 10 mail.example.com. |
| CNAME (Canonical Name) | Creates an alias (nickname) for another domain name. | ftp IN CNAME web.example.com. |
🌐 Full Master-Client-Slave DNS Setup Example
Let's configure a small internal network using the domain internal.local and the subnet 192.168.10.0/24.
| Machine | Role | IP Address | Hostname (FQDN) |
|---|---|---|---|
| Server 1 (Master) | Primary DNS | 192.168.10.10 |
ns1.internal.local |
| Server 2 (Slave) | Secondary DNS | 192.168.10.20 |
ns2.internal.local |
| Client | Workstation | 192.168.10.50 |
client.internal.local |
Step 1: Configure the Primary DNS Server (Master) - 192.168.10.10
A. Edit /etc/named.conf (Master)
We define the global options, the forward zone for internal.local, and the reverse zone for 192.168.10.x. Note the crucial allow-transfer setting.
options {
listen-on port 53 { 127.0.0.1; 192.168.10.10; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
allow-query { any; };
// Other options here...
};
// Forward Zone
zone "internal.local" IN {
type master;
file "internal.local.zone"; // Zone file location
allow-transfer { 192.168.10.20; }; // Allow transfer to Slave
notify yes; // Notify the slave of zone changes
};
// Reverse Zone for 192.168.10.x
zone "10.168.192.in-addr.arpa" IN {
type master;
file "10.168.192.rev";
allow-transfer { 192.168.10.20; }; // Allow transfer to Slave
notify yes;
};
B. Create Forward Zone File /var/named/internal.local.zone
The SOA serial number must be increased every time the zone file is modified to trigger a zone transfer to the slave.
$TTL 86400
@ IN SOA ns1.internal.local. admin.internal.local. (
2025092701 ; Serial YYYYMMDDNN
3600 ; Refresh (1 hour)
1800 ; Retry (30 minutes)
604800 ; Expire (1 week)
86400 ) ; Minimum TTL (1 day)
@ IN NS ns1.internal.local.
@ IN NS ns2.internal.local. ; Slave NS
ns1 IN A 192.168.10.10
ns2 IN A 192.168.10.20
client IN A 192.168.10.50
web IN A 192.168.10.60
C. Create Reverse Zone File /var/named/10.168.192.rev
Note that only the last octet of the IP is used for the PTR record.
$TTL 86400
@ IN SOA ns1.internal.local. admin.internal.local. (
2025092701 ; Serial
3600 ; Refresh (1 hour)
1800 ; Retry (30 minutes)
604800 ; Expire (1 week)
86400 ) ; Minimum TTL (1 day)
@ IN NS ns1.internal.local.
@ IN NS ns2.internal.local.
10 IN PTR ns1.internal.local.
20 IN PTR ns2.internal.local.
50 IN PTR client.internal.local.
60 IN PTR web.internal.local.
D. Check and Start/Reload
$TTL 86400
@ IN SOA ns1.internal.local. admin.internal.local. (
2025092701 ; Serial
3600 ; Refresh (1 hour)
1800 ; Retry (30 minutes)
604800 ; Expire (1 week)
86400 ) ; Minimum TTL (1 day)
@ IN NS ns1.internal.local.
@ IN NS ns2.internal.local.
10 IN PTR ns1.internal.local.
20 IN PTR ns2.internal.local.
50 IN PTR client.internal.local.
60 IN PTR web.internal.local.
Step 2: Configure the Secondary DNS Server (Slave) - 192.168.10.20
The slave server's configuration is much simpler; it only needs to know the master's IP and its role as a slave.
A. Edit /etc/named.conf (Slave)
The type is set to slave, and the masters section points to the master server.
$TTL 86400
@ IN SOA ns1.internal.local. admin.internal.local. (
2025092701 ; Serial YYYYMMDDNN
3600 ; Refresh (1 hour)
1800 ; Retry (30 minutes)
604800 ; Expire (1 week)
86400 ) ; Minimum TTL (1 day)
@ IN NS ns1.internal.local.
@ IN NS ns2.internal.local. ; Slave NS
ns1 IN A 192.168.10.10
ns2 IN A 192.168.10.20
client IN A 192.168.10.50
web IN A 192.168.10.60
B. Start Slave named
Start/Enable BIND
systemctl enable named
systemctl start named
The slave server will contact the master server (192.168.10.10) and perform a zone transfer to pull the zone data, creating the zone files (e.g., slaves/internal.local.zone) automatically. Check /var/log/messages or BIND's specific logs for confirmation.
Step 3: Configure the Client Machine - 192.168.10.50
The client simply needs to be configured to use the DNS servers.
A. Edit /etc/resolv.conf (Client)
Set the master and slave IPs as the primary and secondary nameservers.
/etc/resolv.conf
nameserver 192.168.10.10 # Master DNS
nameserver 192.168.10.20 # Slave DNS
search internal.local
Note: On modern Linux distributions using NetworkManager or systemd-resolved, you might need to configure the DNS settings through the network configuration files/tools instead of manually editing resolv.conf.
B. Test Resolution (Client)
Use dig to test the setup.
Test forward lookup on the master
dig @192.168.10.10 web.internal.local
Test forward lookup on the slave
dig @192.168.10.20 web.internal.local
Test reverse lookup (PTR)
dig @192.168.10.10 -x 192.168.10.50
Top comments (0)