Self-hostedDNS hostingCapabilities verified
FortiGate DNS
Migrate DNS zones to or from FortiGate DNS: what's supported, what access you need, and what changes for each destination.
See how a domain's records would land at FortiGate. Free and read-only.
Access we need
- Credentials
- Management URL + REST API admin token (Bearer) + VDOM
- Permissions
- Admin profile with System → Configuration read for the preview, read/write to apply; restrict the REST API admin with trusted hosts.
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 FortiGate 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
- auto
Record types
- A
- AAAA
- CNAME
- MX
Good to know
- FortiGates usually sit on private networks: we only connect if the admin HTTPS interface is exposed on a public address with a valid certificate, because private and internal addresses are refused by design.
- Only A, AAAA and CNAME records plus MX at the zone apex are supported; wildcards, TXT, SRV and CAA are not, and disabled entries are left untouched.
- Every change rewrites the zone's whole dns-entry table; we read and merge first so records outside the plan survive, but concurrent edits in the GUI can be overwritten.