Self-hostedDNS hostingCapabilities verified
RFC 2136 dynamic DNS (AXFR + DDNS)
Migrate DNS zones to or from RFC 2136 dynamic DNS (AXFR + DDNS): what's supported, what access you need, and what changes for each destination.
See how a domain's records would land at AXFR/DDNS. Free and read-only.
Access we need
- Credentials
- Primary server + TSIG key (HMAC-SHA256/512; SHA1/MD5 for legacy servers)
- Permissions
- The TSIG key needs zone-transfer (AXFR) rights for the preview and an update-policy grant for the managed zones to apply.
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 AXFR/DDNS 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
- We reach the primary only over TCP port 53 at a public address; servers on private networks must expose port 53 publicly and allow our egress IPs.
- Zones can't be listed or created over DNS: list them in the connection and create them on the server first.
- Records of types we can't encode (e.g. LOC, CERT) and DNSSEC records are skipped when reading; signing stays with the server.