DNS zone transfers, the mechanism by which secondary DNS servers obtain zone data from primary servers, are a critical component of DNS infrastructure. The two primary methods, AXFR (full zone transfer) and IXFR (incremental zone transfer), offer different approaches to keeping secondary servers synchronized.
Here’s a look at how to configure these, focusing on BIND, a widely used DNS server software.
Setting Up AXFR (Full Zone Transfer)
AXFR is the simpler of the two, but less efficient. It involves the secondary server requesting and receiving the entire zone file from the primary.
Primary Server Configuration (named.conf):
On your primary BIND server, you need to allow zone transfers to specific secondary servers. This is done within the zone definition in your named.conf file.
zone "example.com" IN {
type master;
file "/var/named/zones/db.example.com";
allow-transfer { 192.168.1.10; 10.0.0.5; }; // IP addresses of secondary servers
};
allow-transfer { 192.168.1.10; 10.0.0.5; };: This directive explicitly lists the IP addresses of the secondary servers that are permitted to request a full zone transfer forexample.com. You can also use network blocks (e.g.,192.168.1.0/24) or even TSIG keys for more secure authentication.
Secondary Server Configuration (named.conf):
On your secondary BIND server, you define the zone as a slave and point it to the primary.
zone "example.com" IN {
type slave;
file "/var/named/slaves/db.example.com";
masters { 192.168.1.1; }; // IP address of the primary server
};
type slave;: This declares the server as a secondary for this zone.masters { 192.168.1.1; };: This specifies the IP address of the primary server from which this secondary server should fetch the zone data.
Why it works: When the secondary server starts or detects a change (via NOTIFY messages from the primary, if configured), it initiates a TCP connection to the primary server on port 53. It then sends a ZONE_TRANSFER query. The primary checks the allow-transfer list, and if the secondary is permitted, it sends the entire zone file. The secondary then writes this to its file location.
Common Pitfalls:
- Firewall blocking TCP port 53: Zone transfers use TCP, not UDP. Ensure firewalls between primary and secondary allow this.
- Incorrect IP in
allow-transfer: Double-check the IP addresses listed on the primary. - Incorrect IP in
masters: Ensure the secondary is pointing to the correct primary IP. - Permissions issues: The BIND process needs read access to the zone file on the primary and write access to the slave directory on the secondary.
Setting Up IXFR (Incremental Zone Transfer)
IXFR is more efficient as it only transfers the changes made to the zone since the last successful transfer. This significantly reduces network traffic, especially for large zones with frequent updates. IXFR relies on the SOA serial number.
Primary Server Configuration (named.conf):
IXFR is enabled by default if your BIND version supports it and your zone is configured correctly. You still need to manage allow-transfer as with AXFR.
zone "example.com" IN {
type master;
file "/var/named/zones/db.example.com";
allow-transfer { 192.168.1.10; 10.0.0.5; };
// auto-notify yes; // Recommended for IXFR to ensure timely updates
};
auto-notify yes;: While not strictly required for IXFR, enablingauto-notifyon the primary tells it to send NOTIFY messages to configured slave servers whenever the zone’s SOA serial number increases. This prompts the slaves to check for updates, making IXFR more effective.
Secondary Server Configuration (named.conf):
The configuration is identical to AXFR for the secondary server. BIND will attempt to use IXFR first. If it fails (e.g., the primary doesn’t support it, or the change log is unavailable), it will fall back to AXFR.
zone "example.com" IN {
type slave;
file "/var/named/slaves/db.example.com";
masters { 192.168.1.1; };
};
How IXFR works:
- The secondary server periodically checks the SOA serial number of the zone on the primary.
- If the serial number on the primary is higher than what the secondary has, the secondary sends a
IXFRquery to the primary. This query includes the SOA serial number the secondary currently possesses. - The primary server looks at its zone change log (BIND maintains this internally if journaling is enabled or if it’s a dynamic zone). It compares the serial number requested by the secondary with its current serial number.
- If the primary has the necessary change records between the secondary’s serial and its current serial, it sends those changes over TCP.
- If the primary doesn’t have the specific change records (e.g., the log has rolled over, or the serial number jump is too large), it will respond with a full AXFR.
- The secondary applies the received changes to its local copy of the zone.
Enabling Zone Journaling (for better IXFR):
BIND 9.x automatically uses a journal file for dynamic DNS updates and IXFR. If you’re not using dynamic DNS, you might want to ensure journaling is implicitly handled or explicitly enabled for better IXFR performance and reliability. For dynamically updated zones, BIND creates a .jnl file (e.g., /var/named/zones/db.example.com.jnl) which stores the transaction log. For static zones, BIND still maintains an internal change history that can be used for IXFR.
Why it works: The SOA serial number is the atomic clock for a DNS zone. Any change to a zone record must result in an incremented SOA serial number. IXFR leverages this by asking: "Give me everything after serial X." The primary then consults its history to fulfill this request efficiently.
Common Pitfalls for IXFR:
- Serial number not incremented: If the administrator forgets to increment the SOA serial number after making a change on the primary, the secondary will not know an update has occurred. This is the most common reason IXFR fails and falls back to AXFR.
- Journal file corruption/loss: If the
.jnlfile on the primary becomes corrupted or is deleted, IXFR might not be able to reconstruct changes, leading to AXFR fallback. - Large serial number jumps: If a zone has been offline for a long time or many changes have occurred, the serial number difference might be too large for the primary to serve via IXFR (e.g., it has rolled over its change log), forcing an AXFR.
- BIND version differences: Older BIND versions might have limited or no IXFR support.
After fixing zone transfer issues: The next error you’ll likely encounter is related to DNSSEC validation failures if your zones are signed.