Cloud platformDNS hostingCapabilities verified
UltraDNS (DigiCert)
Migrate DNS zones to or from UltraDNS (DigiCert): what's supported, what access you need, and what changes for each destination.
See how a domain's records would land at UltraDNS. Free and read-only.
Access we need
- Credentials
- API user name and password (OAuth password grant)
- Permissions
- Create a dedicated API-only user in a group limited to DNS operations (the built-in TECHNICAL group, or a custom group with DNS read and write). A REPORTING or ungrouped user is enough for a read-only preview. The REST API doesn't support multi-factor login, so MFA must be off for this user.
What UltraDNS 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
- ALIAS
- DS
- HTTPS
- SVCB
- TLSA
- SSHFP
- NAPTR
- SPF
- RP
Good to know
- Traffic-management pools (SiteBacker, Traffic Controller, Directional and Simple Load Balancing) are copied as plain answers and flagged; we never change or delete them on UltraDNS.
- Resource Distribution pools keep their pool settings when we update their answers.
- ALIAS is written as UltraDNS Apex Alias, which only works at the zone apex, can't coexist with both A and AAAA at the apex, and can't be used in statically signed zones.
- SOA, apex NS and system-generated records (such as Valimail DMARC records) are managed by UltraDNS and left untouched.
- Web Forwards and secondary or alias zones aren't migrated; secondary and alias zones are read-only.
- UltraDNS locks an account after repeated failed logins, so double-check the password before retrying.