What a DNS zone is and when it gets migrated
A DNS zone is a file with the records for one domain: A, AAAA, MX, TXT, CNAME, NS. A zone gets migrated when you switch DNS hosting, move from BIND to PowerDNS, or consolidate several name servers into one.
Before migrating, export the current zone to a text format — this serves as a backup in case of an error and as the source for importing on the new server.
Exporting a zone from BIND
Zone files in BIND are usually located in /etc/bind/zones/ or /var/named/. Check and export the zone with the following command:
named-compilezone -f text -o example.com.zone example.com /etc/bind/zones/db.example.com
cat example.com.zone
If the zone is stored in a database (BIND with DLZ) or file access is restricted, export the zone via an AXFR request from a server that has transfer permission.
Transferring a zone with AXFR between BIND servers
AXFR is a protocol for a full zone transfer between name servers. On the old server, allow the transfer for the new IP address in named.conf:
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
allow-transfer { 203.0.113.10; };
};
On the new server, request the zone:
dig axfr example.com @203.0.113.5
Save the resulting output as a zone file and load it as a master zone on the new server.
Importing a zone into PowerDNS
PowerDNS stores zones in a database (MySQL, PostgreSQL, or SQLite) rather than in text files. Import the zone with the pdnsutil utility:
pdnsutil create-zone example.com
pdnsutil load-zone example.com example.com.zone
pdnsutil rectify-zone example.com
The rectify-zone command is required for zones with DNSSEC or a large number of records — it recalculates the internal fields in the PowerDNS database.
Verifying the zone before switching over
Compare the record counts and the content of key fields on the old and new server:
dig +short A example.com @old-ns
dig +short A example.com @new-ns
dig +short MX example.com @new-ns
Also check the zone's serial number (SOA) — it must be higher than on the old server, otherwise secondary name servers will refuse the update. The general approach to a zero-downtime transfer is covered in the article on managing DNS during a migration.
How to avoid downtime when changing NS servers
Lower record TTLs to 300 seconds 24-48 hours before the transfer — this speeds up the propagation of changes. Keep the old name servers running for at least 72 hours after changing the NS records at the registrar: some resolvers cache old NS records longer than they should.
Summary: DNS zone migration checklist
- Export the current zone to a text file as a backup.
- Transfer the zone via AXFR or a manual import into PowerDNS.
- Lower record TTLs 24-48 hours before switching over.
- Check the SOA serial number and the content of the A, MX, and TXT records.
- Keep the old name servers active for at least 72 hours after the switch.
- Keep a list of subdomains with separate delegation — those NS records get checked separately, and they are a common source of discrepancies after the transfer.
If something goes wrong after changing the NS records, the recovery procedure is covered in the migration rollback plan. After the full switch, verify the site with the general post-migration checklist.