How to export a DNS zone file from Cloudflare, Route 53, GoDaddy, Azure and more
Export a DNS zone file from Cloudflare, Route 53, GoDaddy, Azure DNS, Google Cloud DNS, Namecheap and more, with provider steps and export limits.
9 min readDNSMigrator team
On this page
An export is a snapshot, not proof that another provider can reproduce the zone. Save the untouched source, record when you took it, and do not change the live zone while you validate the copy. If this is preparation for a move, start with the DNS migration checker as well as the file.
Export DNS zone file data safely#
Prefer the source provider's own export over scraping its dashboard or copying public answers. Public DNS cannot reveal unqueried names, and a proxied or flattened answer may not contain the configured target. A provider API can also expose metadata that BIND has no standard field for.
Use the current provider-specific path below. Commands use documentation names such as example.com; replace IDs, resource groups, projects, and file paths with yours. Never paste an API token directly into shell history.
Provider exports: Cloudflare, Route 53, Azure, and more#
For a Cloudflare export DNS zone file, open the zone's DNS Records page, select Import and Export, then select Export. Cloudflare's current import and export documentation says the download is BIND format.
The API equivalent requires a token with DNS Read or DNS Write and the zone ID:
curl --fail --silent --show-error \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/export" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--output example.com.zoneCloudflare now writes comments, tags, cf-proxied state, and per-record flattening into semicolon comments with reserved cf- tags. DNSMigrator’s release parser treats those annotations as comments and does not preserve them, so use a Cloudflare API connection when proxy or comment metadata matters. Page Rules, Redirect Rules, Workers routes, load balancers, and other application features are not ordinary DNS records. Review what changes when leaving Cloudflare and the Cloudflare connection guide.
What DNS exports miss#
A BIND file represents resource records: owner, TTL, class, type, and RDATA. It does not have standard fields for these common provider features:
- Cloudflare proxying, redirects, Workers routes, page rules, load balancers, or account settings. Cloudflare's
cf-comments preserve some DNS-record flags only for software that understands them. - Route 53 aliases, health checks, weighted, latency, geolocation, geoproximity, failover, multivalue, and traffic-policy relationships. AWS JSON is the lossless source for those fields.
- Azure resource aliases and Google Cloud routing policies.
- Registrar URL forwarding, email forwarding, synthetic records, or templates.
- Record comments, tags, ownership labels, protection flags, and audit history unless a provider emits a private convention.
Exports may also contain DNSSEC-generated DNSKEY, RRSIG, NSEC, or NSEC3 data. Do not copy an old provider's signatures into a newly signed destination. Plan the chain-of-trust change with the DNSSEC migration guide and check it with the DNSSEC checker.
Handle SOA and NS records deliberately#
The apex SOA and authoritative NS records describe the current provider. Most managed destinations create their own versions when the zone is created. Importing the old apex set can conflict, fail, or advertise servers that do not host the new zone. Remove or replace them only according to the destination's import documentation.
Delegation NS records below the apex are different: they may intentionally hand a child zone to other servers and usually must move. Glue A or AAAA records may matter too. Do not apply a blanket “delete every NS line” rule.
Comments beginning with ; are legal master-file comments, but they are not DNS answers. Some exporters preserve them, some synthesize them, and some discard them. Never make a migration depend on a comment surviving.
Validate and translate the file before import#
Keep the untouched export
Store the original BIND, JSON, YAML, or XML response beside its timestamp. Make edits in a copy so you can always return to the provider's exact output.
Parse the zone file
Paste the copy into the zone file validator. It catches malformed directives, missing origins, unsupported record types, and broken parentheses, then emits fully qualified names that help you spot relative-target mistakes before they reach a provider. The BIND zone file format guide explains every column.
Translate for the destination
Use the zone translator to see which records stay exact, which need a provider representation, and which cannot be carried in BIND. Resolve warnings rather than deleting unfamiliar lines.
Compare control plane and DNS answers
Compare source and candidate data with the DNS record diff, then query the new nameservers directly. The dig command examples show how to require an authoritative answer before delegation.
Export DNS records to CSV only for review#
CSV is not a DNS interchange standard. It has no agreed schema for multi-value RRsets, quoted TXT strings, aliases, routing policies, or provider metadata. Do not convert a zone file to CSV with whitespace splitting: spaces are valid inside TXT and several RDATA formats.
If you need a spreadsheet inventory, convert a structured API response with explicit columns and keep the source JSON. For Cloudflare, the official list API allows up to 5,000,000 records per page and returns name, type, ttl, content, proxied, and comment. This review-only conversion preserves each API content string as one CSV field:
curl --fail --silent --show-error \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?per_page=5000000" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" |
jq -r '
["name", "type", "ttl", "content", "proxied", "comment"],
(.result[] | [.name, .type, .ttl, .content, (.proxied // false), (.comment // "")])
| @csv
' > records.csvThat CSV intentionally omits tags, settings, timestamps, and other metadata. It is a report, not a restorable backup. For other providers, define a provider-specific schema rather than pretending all JSON record objects have the same shape.
When DNSMigrator can skip the file#
A zone file remains useful for an archive or an offline source. For a provider-to-provider move, DNSMigrator can instead connect to the source provider, read configured records and supported metadata through its API, normalize them, and preview destination translations. Preview and migration apply do not write the source; the optional cutover TTL-lowering step is the one explicit exception and updates eligible source TTLs.
Use BIND zone files as a migration source when API access is unavailable. Otherwise, follow the quickstart: connect source and destination, preview, apply, verify the destination authorities, then cut over. Keep the export anyway; a migration plan and an independent backup answer different questions.
How do I export a DNS zone file?
Can I export DNS records from Cloudflare?
GET /zones/{zone_id}/dns_records/export with DNS Read. Cloudflare includes some private state as cf- tags, but non-DNS features still need a separate inventory.How do I export a DNS zone from Route 53?
aws route53 list-resource-record-sets JSON for a lossless control-plane inventory; use cli53 export --full only when you also need a BIND-like conversion.