Exporting and importing a DNS zone without losing records

A DNS zone is the full set of records for your domain: where the website lives, which server receives mail, SPF, DKIM and DMARC, and verification codes for various services. These records pile up over years and rarely does anyone hold a complete list. When DNS moves to a new provider, one forgotten record can stop mail or break a payment integration, so exporting and importing a zone correctly is a valuable skill. An exported zone file is also a useful backup before any large DNS change, and a good starting point for auditing which records are still needed.

What a zone file contains

The standard text format, known as BIND format, is understood by almost every DNS server and panel. Each line holds a name, TTL, class, type and value, preceded by $ORIGIN, $TTL, the SOA record and the NS list.

$ORIGIN example.uz.
$TTL 3600
@      IN  SOA  ns1.provayder.uz. hostmaster.example.uz. ( 2026110401 3600 900 1209600 300 )
@      IN  NS     ns1.provayder.uz.
@      IN  A      203.0.113.10
www    IN  CNAME  example.uz.
@      IN  MX     10 mail.example.uz.
mail   IN  A      203.0.113.20
@      IN  TXT    "v=spf1 ip4:203.0.113.20 ~all"

Watch the trailing dots: mail.example.uz. is absolute, while mail without a dot gets $ORIGIN appended. A missing dot produces names like mail.example.uz.example.uz.

Exporting the zone

The best option is your panel's export feature, because the file includes subdomains you may have forgotten. Zone transfer (dig AXFR example.uz @ns1.provayder.uz) gives the whole zone in one query but is usually restricted to authorised IPs. Failing both, query each type separately, since many servers no longer answer ANY fully. You will only find names you know, so list DKIM selectors, _dmarc, autodiscover and verification records in advance.

for t in A AAAA MX TXT CAA NS; do dig +noall +answer $t example.uz; done
dig +noall +answer TXT _dmarc.example.uz

Validating the file

named-checkzone example.uz example.uz.zone

The tool ships with bind9-utils or bind-utils. Also check by eye that long DKIM keys are joined correctly, TXT quotes are closed and there is no CNAME at the zone apex, which the standard forbids.

Importing

Do not import the old SOA and NS records; the new provider creates its own. Add the rest via the panel's import feature or one by one, then query the new name servers directly and compare their answers with the old ones while the domain still points to the old NS:

for t in A MX TXT; do
  diff <(dig +short $t example.uz @ns1.eski.uz | sort) \
       <(dig +short $t example.uz @ns1.yangi.uz | sort) && echo "$t: match"
done

Planning the cutover

Lower the TTL of key records, for example to 300 seconds, a day or two before switching. NS delegation is cached at the parent zone independently of your TTL, so the full switch can take hours to a day or two. If DNSSEC is enabled, disable it properly or re-sign with the new provider's keys before the move, or the domain may stop resolving.

Example: a hotel in Bukhara

A family hotel in Bukhara moves its site and mail to new hosting. Its zone has the website, mail, a booking-system subdomain, a search engine verification record and a payment service TXT code. The administrator exports the zone, validates it with named-checkzone, strips SOA and NS, imports it and confirms with the diff script that both sets of servers agree before changing NS. Bookings and mail continue without interruption, and the hotel keeps the exported file as a record of the old configuration. After adding records in the sayt.uz cabinet's DNS section, check them with a direct dig query to the new name servers before switching NS.