Record types

DNSMigrator’s release model has 44 canonical record types: standard DNS records, redirect shortcuts, and provider-specific pseudo-records. The key point is that the Type menu uses the union advertised by the assigned providers; a type can appear even when another assigned provider cannot accept it.

How to read this reference#

The support counts below come from the release provider catalog. They include the 65 connectable, writable DNS destinations and exclude the BIND file module and DNS modules marked as planned. Open Supported providers to confirm a destination’s current capability list.

Examples use zone-file layout for readability:

owner  TTL  IN  TYPE  RDATA

@ means the zone apex. DNS names are stored in lowercase with a trailing dot. TXT and SPF values are stored as logical text without outer quotes.

Common record types#

These types have dedicated fields in the record editor.

CNAME, ALIAS, and DNAME are single-value in the form. NS and PTR use the same hostname field but may hold several values. Types without a dedicated editor use Record data, which checks only that the value is nonempty before saving unless a specific lint rule applies.

DNSSEC, service binding, and security records#

A DS for this zone belongs at its parent or registrar. An in-zone DS normally accompanies an NS delegation for a child. Use Settings → DNSSEC for provider-managed signing and follow DNSSEC transitions when changing delegation.

Other standard records#

The nine LOC destinations are Cloudflare, Akamai, CentralNic, deSEC, Gandi, Loopia, Oracle Cloud, OVHcloud, and Realtime Register.

Redirect and mail shortcut types#

These are control-plane shortcuts rather than portable DNS wire types. The BIND parser does not accept them as zone-file record types.

When a migration destination lacks the same shortcut, translation marks it as a provider redirect feature instead of inventing equivalent HTTP behavior.

Cloudflare pseudo-records#

The release catalog exposes four Cloudflare-only pseudo-types. They use raw Record data in the editor and are not accepted by the BIND parser.

The dnsconfig.js constructor for CF_SINGLE_REDIRECT accepts 301, 302, 303, 307, or 308. Cloudflare proxying is separate: ordinary A, AAAA, and CNAME records use Proxy through Cloudflare metadata.

Akamai, ClouDNS, PowerDNS, and appliance types#

The two AdGuard passthrough types and MIKROTIK_NXDOMAIN require an empty canonical value. The release web save guard rejects empty non-alias values, so they cannot currently be created or imported successfully as managed-zone records.

Alias constructors in dnsconfig.js#

R53_ALIAS and AZURE_ALIAS are constructor names, not canonical record types. The importer converts them to ordinary records with alias metadata:

R53_ALIAS("cdn", "A", "d111111abcdef8.cloudfront.net.", R53_EVALUATE_TARGET_HEALTH(true), R53_ZONE("Z2FDTNDATAQYW2"))
AZURE_ALIAS("app", "A", "/subscriptions/0000/resourceGroups/dns/providers/Microsoft.Network/publicIPAddresses/app")

A Route 53 alias stores an allowed Route 53 record type with no ordinary values, plus a DNS target, optional hosted-zone ID, and optional health evaluation. The direct editor exposes aliases only for A and AAAA. An Azure alias stores A, AAAA, or CNAME with a resource ID and is available only by loading dnsconfig.js.

For the exact runtime function list and import losses, see dnsconfig.js import and export. Use the zone file validator for the release BIND parser’s standard-type and directive coverage.