================================================================================
DNS SERVER SETUP GUIDE — BIND MASTER/SLAVE SETUP
================================================================================
Author : Tushar Sonawane
Date : 09 September 2026
================================================================================
Prepared for: Local Master-Slave DNS Server Implementation
Master IP : 192.168.1.19 (ns1.example.com)
Slave IP : 192.168.1.5 (ns2.example.com)
Domain : example.com
================================================================================
TABLE OF CONTENTS
-----------------
1. Introduction to DNS
2. DNS Record Types — Detailed Reference
3. BIND Package Installation.
4. DNS Server Configuration (Master & Slave)
4a. named.conf
4b. Forward Zone File
4c. Reverse Zone File
5. Master-Slave Configuration Explained
6. Entry for DNS Server in /etc/resolv.conf
7. Record Verification Commands
8. Conclusion
================================================================================
1. INTRODUCTION TO DNS
================================================================================
DNS stands for Domain Name System. It is a hierarchical, distributed naming
system that translates human-readable domain names (like www.example.com) into
machine-readable IP addresses (like 192.168.1.19), and vice versa.
Without DNS, users would need to remember the numeric IP address of every
website or server they want to reach. DNS acts as the "phone book" of the
internet, making navigation simple and scalable.
HOW DNS WORKS — QUERY FLOW
---------------------------
When a user types "www.example.com" in a browser, the following happens:
Step 1 — Local cache check
The OS checks its own DNS cache. If the answer is stored, it
returns immediately without going to any server.
Step 2 — Recursive resolver
If not cached, the query goes to the configured DNS resolver
(defined in /etc/resolv.conf). This is organization's internal DNS server.
Step 3 — Root name servers
The resolver asks a root name server (.) which name server is
responsible for the ".com" top-level domain (TLD).
Step 4 — TLD name servers
The resolver asks the .com TLD server which name server is
authoritative for "example.com".
Step 5 — Authoritative name server
The resolver queries the authoritative DNS server (ns1.example.com
or ns2.example.com in our setup) which returns the actual IP
address for www.example.com.
Step 6 — Response returned
The resolver sends the answer back to the client. The result is
cached for the duration of the TTL (Time To Live) value.
DNS SERVER TYPES
----------------
Authoritative Server — Holds the actual zone data. Answers queries about
domains it is responsible for. This is what we are
building. Can be Master (Primary) or Slave (Secondary).
Recursive Resolver — Does not hold zone data. Queries other servers on
behalf of clients and returns the final answer.
Caching Server — Stores answers from previous lookups to speed up
future queries.
Forwarding Server — Forwards all queries to another specified DNS server
instead of resolving them itself.
KEY CONCEPTS
------------
Zone — A zone is a portion of the DNS namespace that a particular
name server manages. Example: "example.com" is a zone.
SOA Record — Start of Authority. Every zone has exactly one SOA record.
It contains the primary name server, admin email, serial
number, and timing values for zone transfers.
TTL — Time To Live. Specifies how long (in seconds) a DNS record
may be cached by resolvers before it must be re-fetched.
Serial — A number in the SOA record that increments every time the
zone changes. The slave uses this to detect updates.
AXFR — Full zone transfer. The slave requests a complete copy of
the zone from the master.
IXFR — Incremental zone transfer. Only changed records are sent,
saving bandwidth.
NOTIFY — When a zone is updated, the master sends a NOTIFY message
to all slave servers so they can pull the updated zone.
================================================================================
2. DNS RECORD TYPES — DETAILED REFERENCE
================================================================================
DNS records are stored in zone files. Each record has a specific type
that defines its purpose. Below is a complete reference of common record types.
------------------------------------------------------------------------------
| Type | Description |
------------------------------------------------------------------------------
| A | Maps a hostname to an IPv4 address. |
| | Example: www IN A 192.168.1.19 |
------------------------------------------------------------------------------
| AAAA | Maps a hostname to an IPv6 address. |
| | Example: www IN AAAA 2001:db8::1 |
------------------------------------------------------------------------------
| NS | Name Server record. Delegates a zone to a name server. |
| | Example: @ IN NS ns1.example.com. |
------------------------------------------------------------------------------
| MX | Mail Exchanger. Specifies the mail server for the domain. |
| | Lower priority number = higher preference. |
| | Example: @ IN MX 10 mail.example.com. |
------------------------------------------------------------------------------
| CNAME | Canonical Name. Creates an alias pointing to another hostname. |
| | Example: ftp IN CNAME www.example.com. |
------------------------------------------------------------------------------
| PTR | Pointer record. Used in reverse zones to map IP to hostname. |
| | Example: 19 IN PTR ns1.example.com. |
------------------------------------------------------------------------------
| SOA | Start of Authority. Contains zone metadata and timing info. |
| | Exactly one per zone. Required in every zone file. |
------------------------------------------------------------------------------
| TXT | Text record. Used for SPF, DKIM, domain verification, etc. |
| | Example: @ IN TXT "v=spf1 mx ~all" |
------------------------------------------------------------------------------
| SRV | Service record. Specifies location of services (e.g. SIP, XMPP). |
| | Example: _sip._tcp IN SRV 10 20 5060 sip.example.com. |
------------------------------------------------------------------------------
| CAA | Cert Authority Authorization. Restricts which CAs can issue |
| | SSL certificates for the domain. |
| | Example: @ IN CAA 0 issue "letsencrypt.org" |
------------------------------------------------------------------------------
| NAPTR | Name Authority Pointer. Used for ENUM and VoIP applications. |
------------------------------------------------------------------------------
SOA RECORD FIELDS EXPLAINED
----------------------------
@ IN SOA ns1.example.com. admin.example.com. (
2024010101 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Negative Cache TTL
ns1.example.com. — Primary (master) name server for this zone.
admin.example.com. — Admin email. The first dot replaces the @ symbol.
(admin.example.com = admin@example.com)
Serial — Version number of zone file. Must be incremented
every time the zone file changes. Format: YYYYMMDDNN
where NN is the change number for that day.
Refresh — How often (seconds) the slave checks the master for
zone updates. 3600 = every 1 hour.
Retry — If the slave cannot reach the master for a refresh,
how long (seconds) to wait before retrying.
1800 = 30 minutes.
Expire — If the slave cannot contact the master for this long,
it stops responding to queries for this zone.
604800 = 7 days.
Negative Cache TTL — How long resolvers cache NXDOMAIN (non-existent
domain) responses. 86400 = 1 day.
================================================================================
3. FILES INSTALLED BY THE BIND PACKAGE
================================================================================
/usr/sbin/named — The main DNS server daemon
/usr/sbin/named-checkconf — Validates named.conf syntax
/usr/sbin/named-checkzone — Validates zone file syntax
/usr/sbin/rndc — Remote Name Daemon Control utility
/etc/named.conf — Main configuration file
/var/named/ — Default zone file directory
/var/named/named.ca — Root hints file (root name servers)
/var/named/localhost.zone — Localhost forward zone
/var/named/named.local — Localhost reverse zone
/etc/rc.d/rc.bind — init script for BIND
NOTE: The named.ca file may be located inside a subdirectory
such as /var/named/caching-example/. If named fails with "named.ca not found",
copy it to /var/named/:
cp /var/named/caching-example/named.ca /var/named/named.ca
chown named:named /var/named/named.ca
chmod 644 /var/named/named.ca
ENABLE BIND AT BOOT
--------------------
chmod +x /etc/rc.d/rc.bind
START / STOP / RESTART BIND
-----------------------------
/etc/rc.d/rc.bind start
/etc/rc.d/rc.bind stop
/etc/rc.d/rc.bind restart
================================================================================
4. DNS SERVER CONFIGURATION
================================================================================
Our setup uses two servers:
Master (Primary) : 192.168.1.19 hostname: ns1.example.com
Slave (Secondary): 192.168.1.5 hostname: ns2.example.com
Domain : example.com
------------------------------------------------------------------------
4a. /etc/named.conf — MASTER SERVER (192.168.1.19)
------------------------------------------------------------------------
Below is the complete named.conf for the master, followed by a line-by-line
explanation of every directive.
----- BEGIN /etc/named.conf (MASTER) -----
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
listen-on { 127.0.0.1; 192.168.1.19; };
listen-on-v6 { none; };
allow-query { any; };
allow-transfer { 192.168.1.5; };
allow-recursion { 127.0.0.1; 192.168.1.0/24; };
recursion yes;
notify yes;
also-notify { 192.168.1.5; };
};
logging {
channel default_log {
file "/var/log/named/named.log" versions 3 size 5m;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category default { default_log; };
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
zone "example.com" IN {
type master;
file "example.com.zone";
allow-update { none; };
allow-transfer { 192.168.1.5; };
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "db.1.168.192";
allow-update { none; };
allow-transfer { 192.168.1.5; };
};
----- END /etc/named.conf (MASTER) -----
EXPLANATION OF EVERY DIRECTIVE
--------------------------------
options { ... }
The global options block. Settings here apply to the entire named process
unless overridden in individual zone blocks.
directory "/var/named";
Tells named where to look for zone files. All file paths in zone blocks
are relative to this directory. So "example.com.zone" means
/var/named/example.com.zone.
pid-file "/var/run/named/named.pid";
Path where named writes its process ID when it starts. Used by the init
script to send signals (stop/restart) to the running process.
The directory /var/run/named/ must exist and be owned by the named user.
listen-on { 127.0.0.1; 192.168.1.19; };
Tells named which IPv4 addresses to listen on for incoming DNS queries.
127.0.0.1 = loopback (local queries from the server itself).
192.168.1.19 = the server's LAN IP (queries from network clients).
Using specific IPs is more secure than listening on all interfaces.
listen-on-v6 { none; };
Disables IPv6 listening since we are using only IPv4 in this setup.
allow-query { any; };
Controls which clients are allowed to send DNS queries to this server.
"any" means all clients can query. You can restrict this to a subnet:
allow-query { 192.168.1.0/24; }; if you want internal-only access.
allow-transfer { 192.168.1.5; };
Controls which servers are allowed to request a full zone transfer (AXFR).
Only the slave server 192.168.1.5 is permitted. This prevents unauthorized
parties from downloading a complete copy of your DNS zone data.
allow-recursion { 127.0.0.1; 192.168.1.0/24; };
Controls which clients can use this server as a recursive resolver.
Recursion means the server will query other DNS servers on the client's
behalf. Restricting this to the local subnet prevents your server from
being used as an open resolver (which can be abused for DDoS attacks).
recursion yes;
Enables recursive query support for clients in the allow-recursion list.
notify yes;
When a zone is updated on the master, named automatically sends a NOTIFY
message to all slave servers listed in NS records and in also-notify.
The slave then initiates a zone transfer to get the updated zone.
also-notify { 192.168.1.5; };
Explicitly sends NOTIFY messages to 192.168.1.5 (the slave) whenever a
zone changes. This is in addition to NS record-based notification.
logging { ... }
Configures where and how named writes log messages.
channel default_log { ... }
Defines a named logging channel called "default_log".
file "/var/log/named/named.log" versions 3 size 5m;
Logs are written to this file. "versions 3" keeps 3 rotated copies.
"size 5m" rotates the log when it reaches 5 megabytes.
severity dynamic;
Log severity level. "dynamic" means it can be changed at runtime using
rndc trace without restarting the server.
print-time yes; — Include timestamp in each log line.
print-severity yes; — Include severity level (info, warning, error) in log.
print-category yes; — Include the category (security, queries, etc.) in log.
category default { default_log; };
Sends all log messages to the "default_log" channel defined above.
zone "." IN { type hint; file "named.ca"; };
The root zone. type "hint" means this file contains the addresses of the
13 root name servers. named uses this to start recursive resolution.
named.ca is provided by the BIND package and rarely needs updating.
zone "localhost" IN { type master; file "localhost.zone"; }
Forward zone for "localhost". Resolves "localhost" to 127.0.0.1.
Provided by BIND package. Do not modify.
zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; }
Reverse zone for 127.0.0.1. Maps 127.0.0.1 back to "localhost".
Provided by BIND package. Do not modify.
zone "example.com" IN { ... }
Your forward DNS zone. This is where A, MX, CNAME, TXT records live.
type master — This server holds the authoritative, editable copy.
file "example.com.zone" — Zone data lives in /var/named/example.com.zone
allow-update { none; } — Disables dynamic DNS updates. Records can only
be changed by editing the file manually.
allow-transfer { 192.168.1.5; } — Only the slave can pull this zone.
zone "1.168.192.in-addr.arpa" IN { ... }
The reverse DNS zone for the 192.168.1.0/24 subnet. Written in reverse
octet order. Maps IP addresses back to hostnames using PTR records.
The notation "1.168.192" represents the network 192.168.1.x reversed.
------------------------------------------------------------------------
4b. /etc/named.conf — SLAVE SERVER (192.168.1.5)
------------------------------------------------------------------------
----- BEGIN /etc/named.conf (SLAVE) -----
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
listen-on { 127.0.0.1; 192.168.1.5; };
listen-on-v6 { none; };
allow-query { any; };
allow-transfer { none; };
allow-recursion { 127.0.0.1; 192.168.1.0/24; };
recursion yes;
};
logging {
channel default_log {
file "/var/log/named/named.log" versions 3 size 5m;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category default { default_log; };
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
zone "example.com" IN {
type slave;
file "slaves/example.com.zone";
masters { 192.168.1.19; };
};
zone "1.168.192.in-addr.arpa" IN {
type slave;
file "slaves/db.1.168.192";
masters { 192.168.1.19; };
};
----- END /etc/named.conf (SLAVE) -----
KEY DIFFERENCES ON THE SLAVE
------------------------------
listen-on { 127.0.0.1; 192.168.1.5; };
The slave listens on its own IP (192.168.1.5) not the master's.
allow-transfer { none; };
The slave does not allow anyone to pull zones from it. Zone data flows
only from master to slave, never slave to another server.
notify and also-notify are ABSENT on the slave.
The slave never initiates zone change notifications. Only the master does.
zone "example.com" IN { type slave; ... }
type slave — This server gets its zone data from the master.
file "slaves/example.com.zone" — The slave stores the transferred zone
in /var/named/slaves/. This directory must exist and be
owned by the named user. The file is written automatically
after a successful zone transfer; you do not create it.
masters { 192.168.1.19; }; — The IP of the master server. The slave
contacts this address to pull zone updates via AXFR/IXFR.
------------------------------------------------------------------------
4c. FORWARD ZONE FILE — /var/named/example.com.zone (on Master only)
------------------------------------------------------------------------
----- BEGIN example.com.zone -----
$TTL 86400
@ IN SOA ns1.example.com. admin.example.com. (
2024010101 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Negative Cache TTL
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
ns1 IN A 192.168.1.19
ns2 IN A 192.168.1.5
@ IN A 192.168.1.19
www IN A 192.168.1.19
mail IN A 192.168.1.19
@ IN MX 10 mail.example.com.
----- END example.com.zone -----
ZONE FILE SYMBOL REFERENCE
----------------------------
$TTL 86400 Default Time To Live for all records in this file (86400
seconds = 24 hours). Individual records can override this.
@ Shorthand for the zone origin, which is the zone name itself
("example.com"). Used to avoid repeating the full domain name.
IN Internet class. All standard DNS records use IN. Rarely
changed.
. The trailing dot on hostnames like "ns1.example.com." is
required and means "fully qualified". Without it, the zone
name would be appended automatically, resulting in
"ns1.example.com.example.com" which is wrong.
------------------------------------------------------------------------
4d. REVERSE ZONE FILE — /var/named/db.1.168.192 (on Master only)
------------------------------------------------------------------------
----- BEGIN db.1.168.192 -----
$TTL 86400
@ IN SOA ns1.example.com. admin.example.com. (
2024010101
3600
1800
604800
86400 )
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
19 IN PTR ns1.example.com.
5 IN PTR ns2.example.com.
----- END db.1.168.192 -----
The PTR records map IP last-octets to hostnames.
"19" means 192.168.1.19 → ns1.example.com.
"5" means 192.168.1.5 → ns2.example.com.
================================================================================
5. MASTER-SLAVE CONFIGURATION — HOW IT WORKS
================================================================================
HOW TO DECLARE MASTER ZONES
-----------------------------
In the master's named.conf, each zone you want to serve is declared as:
zone "zonename" IN {
type master;
file "zonefile";
allow-transfer { slave-ip; };
};
type master — This server owns and can edit the zone.
file — Path (relative to directory) of the zone data file.
allow-transfer — List of IPs allowed to do AXFR. Restrict to slave IPs only.
HOW TO DECLARE SLAVE ZONES
----------------------------
In the slave's named.conf, each zone is declared as:
zone "zonename" IN {
type slave;
file "slaves/zonefile";
masters { master-ip; };
};
type slave — This server gets its data from a master.
file — Where to cache the transferred zone locally. Must be
writable by the named user. Directory must exist first.
masters — IP address of the master server to pull zone data from.
You can list multiple masters for redundancy:
masters { 192.168.1.19; 192.168.1.20; };
HOW ZONE TRANSFER IS TRIGGERED
--------------------------------
Automatic via NOTIFY:
1. Admin edits zone file on master, increments serial number.
2. Admin runs: rndc reload example.com
3. Master sends NOTIFY packet to slave (192.168.1.5 port 53).
4. Slave compares master's serial with its own.
5. If master serial > slave serial, slave initiates AXFR/IXFR.
6. Zone is transferred over TCP port 53.
7. Slave writes the new zone to /var/named/slaves/.
Automatic on slave startup:
When the slave named process starts, it immediately contacts the master
and checks if a zone transfer is needed.
Manual trigger (from slave):
rndc retransfer example.com
HOW TO ADD A NEW ZONE TO MASTER-SLAVE SETUP
---------------------------------------------
Step 1: Create zone file on master:
nano /var/named/newdomain.com.zone
Step 2: Add zone block in master's named.conf:
zone "newdomain.com" IN {
type master;
file "newdomain.com.zone";
allow-update { none; };
allow-transfer { 192.168.1.5; };
};
Step 3: Add zone block in slave's named.conf:
zone "newdomain.com" IN {
type slave;
file "slaves/newdomain.com.zone";
masters { 192.168.1.19; };
};
Step 4: Reload both servers:
On master: rndc reload
On slave: rndc reload (or restart: /etc/rc.d/rc.bind restart)
HOW TO UPDATE AN EXISTING ZONE
--------------------------------
Step 1: Edit zone file on master ONLY:
nano /var/named/example.com.zone
Step 2: Increment the serial number (e.g. 2024010101 to 2024010102).
THIS IS MANDATORY. If serial does not increase, the slave will
not pull the update, thinking nothing has changed.
Step 3: Reload the zone on master:
rndc reload example.com
Step 4: Master sends NOTIFY to slave automatically. Slave fetches update.
================================================================================
6. ENTRY FOR DNS SERVER IN /etc/resolv.conf
================================================================================
The /etc/resolv.conf file tells the operating system which DNS servers to use
for name resolution. It must be configured on every machine that should use
your new DNS servers.
FORMAT OF /etc/resolv.conf
----------------------------
domain example.com
search example.com
nameserver 192.168.1.19
nameserver 192.168.1.5
FIELD-BY-FIELD EXPLANATION
----------------------------
domain example.com
Sets the local domain name. When you type a short hostname (e.g. "mail")
without a dot, the OS automatically appends this domain and looks up
"mail.example.com". Only one domain directive is allowed.
search example.com
A search list of domains to try when resolving unqualified hostnames.
For example, "ping fileserver" would try "fileserver.example.com".
You can list multiple domains: search example.com internal.example.com
(The "domain" and "search" directives are mutually exclusive; use one.)
nameserver 192.168.1.19
Primary DNS server. All queries go here first. This is our master server.
nameserver 192.168.1.5
Secondary DNS server. Used if the primary does not respond within the
timeout period. This is our slave server. Providing both ensures
redundancy — if the master is down, DNS resolution continues via slave.
NOTES ON resolv.conf
---------------------
- Maximum 3 nameserver entries are allowed.
- On Server, /etc/resolv.conf is a plain static file. Edit it directly.
example nameserver entry
nameserver 192.168.1.15
================================================================================
7. RECORD VERIFICATION COMMANDS
================================================================================
After setting up both servers, verify everything is working correctly.
VALIDATE CONFIGURATION FILES (before starting)
------------------------------------------------
# Check named.conf syntax
named-checkconf /etc/named.conf
# Check forward zone file
named-checkzone example.com /var/named/example.com.zone
# Check reverse zone file
named-checkzone 1.168.192.in-addr.arpa /var/named/db.1.168.192
All commands should return no output (for named-checkconf) or "OK".
CHECK NAMED IS RUNNING
------------------------
ps aux | grep named
rndc status
netstat -ntplu | grep :53
BASIC DIG QUERIES
------------------
# Query master for A record
dig @192.168.1.19 www.example.com
# Query slave for A record (should return same result)
dig @192.168.1.5 www.example.com
# Query for NS records
dig @192.168.1.19 NS example.com
# Query for MX records
dig @192.168.1.19 MX example.com
# Short output (just the answer)
dig @192.168.1.19 www.example.com +short
REVERSE LOOKUP (PTR records)
------------------------------
dig @192.168.1.19 -x 192.168.1.19
dig @192.168.1.5 -x 192.168.1.5
VERIFY ZONE TRANSFER HAPPENED ON SLAVE
----------------------------------------
# Zone files should appear here after transfer
ls -la /var/named/slaves/
# Watch transfer happen in real time
tail -f /var/log/named/named.log
# Expected log entry on success:
# transfer of 'example.com/IN' from 192.168.1.19#53: Transfer completed
MANUALLY TRIGGER ZONE TRANSFER (run on slave)
----------------------------------------------
rndc retransfer example.com
rndc retransfer 1.168.192.in-addr.arpa
TEST WITH NSLOOKUP ( Works for global dns records )
-------------------
nslookup www.example.com 192.168.1.19
nslookup www.example.com 192.168.1.5
nslookup 192.168.1.19 192.168.1.19
TEST FULL AXFR (zone transfer test from command line)
------------------------------------------------------
# This should succeed from the slave IP
dig @192.168.1.19 example.com AXFR
# This should FAIL from any other IP (transfer is restricted)
dig @192.168.1.19 example.com AXFR # from a third machine
USEFUL RNDC COMMANDS
---------------------
rndc status — Show server status and stats
rndc reload — Reload all zones from disk
rndc reload example.com — Reload specific zone only
rndc retransfer example.com — Force slave to re-fetch zone from master
rndc flush — Flush DNS cache
rndc dumpdb — Dump cache to file
rndc trace — Increase logging verbosity
rndc notrace — Return to normal log level
rndc stop — Gracefully stop named
================================================================================
8. CONCLUSION
================================================================================
A properly configured BIND Master-Slave DNS setup provides:
High Availability
If the master server (192.168.1.19) goes offline, the slave server
(192.168.1.5) continues answering DNS queries for the zone. Clients
configured with both nameservers in resolv.conf experience no downtime.
Load Distribution
DNS queries are distributed between master and slave, reducing load
on any single server.
Data Integrity
Zone files exist only on the master in editable form. The slave
receives read-only copies via authenticated zone transfer, reducing
the risk of accidental modification.
Automatic Synchronization
The NOTIFY + AXFR mechanism ensures the slave always has an up-to-date
copy of the zone within seconds of any change on the master.
OPERATIONAL CHECKLIST
----------------------
- BIND installed on both servers
- named.ca (root hints) present in /var/named/ on both servers
- /var/run/named/ directory exists on both servers
- /var/log/named/ directory exists on both servers
- /var/named/slaves/ directory exists on slave, owned by named
- Zone files created on master only
- named-checkconf passes on both servers
- named-checkzone passes for all zones on master
- BIND started and enabled at boot (chmod +x /etc/rc.d/rc.bind)
- Zone transfer confirmed in /var/log/named/named.log on slave
- dig queries return correct results from both servers
- /etc/resolv.conf updated on all client machines
- Firewall rules allow UDP/TCP port 53
IMPORTANT REMINDERS
--------------------
1. Always increment the serial number in the SOA record whenever you
change a zone file. Without this the slave will not pull the update.
2. Run named-checkconf and named-checkzone before every restart to
catch syntax errors before they cause an outage.
3. Never edit zone files on the slave. All changes go on the master
only. The slave's zone files in /var/named/slaves/ are managed
automatically by BIND.
4. Keep both servers' clocks in sync using NTP. Time drift can cause
TSIG authentication failures if you implement key-based zone
transfer security.
5. Backup /etc/named.conf and /var/named/*.zone regularly. These files
are the sole source of truth for your DNS infrastructure.
================================================================================