Self-hostedDNS hostingCapabilities verified
Zone transfer (AXFR/IXFR)
Migrate DNS zones to or from Zone transfer (AXFR/IXFR): what's supported, what access you need, and what changes for each destination.
See how a domain's records would land at Zone transfer. Free and read-only.
Access we need
- Credentials
- Primary server(s) that allow zone transfers to our egress IP, optionally with a TSIG key
- Permissions
- Read-only: the primary must allow AXFR (and ideally IXFR) to our egress IP, optionally restricted to a TSIG key. Nothing is ever written back.
Runs on your own infrastructure.
We connect to its API over the internet, so the API endpoint must be reachable on a public address over HTTPS. We never connect to private or internal addresses.
What Zone transfer supports
The same data the translation engine uses when it plans a migration.
- Create zones through the API
- List zones through the API
- Turn on DNSSEC through the API
- Apex CNAME (flattening)
- Apex ALIAS record
- Aliases to cloud resources
- CDN proxy on records
- Routing policies
- Minimum TTL
- 0s
Record types
- A
- AAAA
- CNAME
- MX
- TXT
- NS
- SRV
- CAA
- PTR
- DS
- TLSA
- SSHFP
- NAPTR
- SPF
- URI
- DNAME
- OPENPGPKEY
- SMIMEA
- DHCID
- RP
- HTTPS
- SVCB
Good to know
- Read-only source: zone transfer connections can be migrated from, monitored and backed up, but never written to.
- We reach primaries only over TCP port 53 at public addresses; private, loopback, link-local and metadata addresses are refused.
- A transfer shows what the server publishes: proxied (CDN) addresses, flattened apex CNAMEs and provider-managed records can't be recovered from it.
- DNSSEC signatures and keys (RRSIG, NSEC/NSEC3, DNSKEY, CDS/CDNSKEY) are dropped; the destination signs the zone itself.
- We can't receive NOTIFY messages, so changes are picked up by polling the SOA serial, then IXFR when the server supports it.