Translation rules

DNSMigrator translates an apex CNAME or ALIAS record against destination capabilities and flags when a Cloudflare proxied record will lose proxying. The preview never assumes two provider features are equivalent: a safe representation is explicit, a behavior-changing fallback is marked Review, and an unrepresentable record is Unsupported.

Rule matrix#

“Supports” means the destination catalog declares that exact capability; check Supported providers.

Warnings and unsupported rows do not have the same apply behavior. Review rows remain in the destination target set. Unsupported and Managed rows do not. Read Previews and record statuses before applying.

How apex CNAME and ALIAS records migrate#

An apex CNAME is provider-specific because the zone apex already needs SOA and NS records. DNSMigrator tests destination options in this order:

1. A recognized Route 53 AWS alias when the destination supports AWS-resource aliases and a hosted-zone ID is known.
2. A provider-native hostname ALIAS when the destination supports it.
3. An apex CNAME when the destination declares flattening support.
4. Supplied current A addresses as a static fallback.
5. Unsupported when none of those representations is available.

For a plain apex CNAME going to Route 53, CloudFront is the special case whose hosted-zone ID is built in. Other recognized AWS hostname patterns—Elastic Load Balancing, S3 website endpoints, API Gateway, Elastic Beanstalk, and Global Accelerator—need a hosted-zone ID carried by source alias metadata before they can remain a Route 53 alias. Without it, the apex needs supplied addresses or is unsupported.

$ORIGIN example.com.
$TTL 300
@    IN CNAME app.example.net.
www  IN CNAME app.example.net.

At Cloudflare, the apex can remain a CNAME and Cloudflare flattens it. At a hostname-ALIAS provider such as Namecheap, it becomes ALIAS. At a destination with neither feature, www can remain an ordinary CNAME, but @ cannot.

When current addresses are supplied to the translation input, an otherwise unsupported apex can become static A records:

@ 300 IN A 198.51.100.10
@ 300 IN A 198.51.100.11

That row is Review because it no longer follows app.example.net when its addresses change. The current web wizard and CLI do not automatically resolve and attach this fallback, so an arbitrary unsupported apex normally requires you to replace it deliberately. For the DNS background, read Apex CNAME, ALIAS and flattening explained.

Route 53 and Azure aliases#

For a side-by-side migration comparison, read Route 53 vs Cloudflare DNS.

Route 53 alias A/AAAA sets carry alias metadata. A recognized AWS target and hosted-zone ID remain an AWS alias where supported; otherwise the representation follows the hostname-ALIAS, flattening-CNAME, non-apex CNAME, static, and unsupported order above. Azure aliases carry a resource ID rather than a portable hostname, so they become supplied static addresses (Review) or Unsupported.

Alias A and AAAA source sets can converge on one CNAME. DNSMigrator merges their source rows, keeps the lowest TTL, and warns if several targets result; one CNAME target is retained.

What happens to Cloudflare proxied records?#

Proxy state is metadata, not DNS data. A proxied Cloudflare record keeps that state only at a proxy-capable destination. Otherwise its address remains, proxied metadata is removed, and the row becomes Review:

Proxied at Cloudflare. After migration, traffic goes straight to 192.0.2.20 without the CDN or WAF.

Confirm that the origin permits public traffic and can handle direct requests. A BIND export from a proxied provider may contain only a CDN address, not the origin, so use the source API when that distinction matters. See How to migrate DNS without downtime.

Routing policies and health checks#

The one-time migration translator always removes routing metadata. For non-failover policies, it combines all unique values at the lowest TTL. For failover, it keeps answers not marked SECONDARY, or the whole group when no primary answer is identifiable. The row is Review, and source health-check IDs are not carried into the target.

Managed-zone planning is separate: it can retain routing metadata only when the attached provider’s catalog advertises that policy. A one-time provider-to-provider migration does not preserve a policy merely because both catalogs list it.

TTL rules#

Every provider catalog entry supplies a minimum, maximum, default, and optionally an “auto” sentinel. The translator applies TTL rules after alias and type conversion:

• A source auto TTL becomes the destination’s auto value when available.
• Otherwise, source auto becomes the destination default and adds an informational note.
• A numeric TTL below the minimum is raised to the minimum.
• A numeric TTL above the maximum is lowered to the maximum.
• An in-range TTL is unchanged.

Clamping is Translated, not Review, because the target remains the same record with a permitted cache duration. The exact bounds differ by provider; do not infer one provider’s limits from another. Check Supported providers or run npx dnsmigrator providers <provider> from the CLI.

For cutover timing rather than provider storage limits, read Lower TTLs before a DNS migration.

TXT and SPF values#

Canonical TXT and SPF values are stored as one logical string without presentation quotes. Adjacent strings in a BIND record are joined during parsing. When a provider or BIND output needs DNS character strings, quoteTxt escapes backslashes and quotes and splits the logical value into 255-character quoted segments:

selector._domainkey 300 IN TXT "v=DKIM1; k=rsa; p=first-part" "second-part"

That representation-only split does not add a migration note; the row can remain Exact. Separately, each provider declares a maximum logical TXT value length. A value longer than that limit is Unsupported rather than truncated. Destinations whose catalog sets a zero TXT limit do not accept TXT through this workflow.

The obsolete SPF RR type is converted to TXT when the destination lacks SPF, producing Translated. Its normalized content is unchanged. Check long DKIM and SPF values against Move DNS without losing email.

Unsupported and provider-managed records#

Standard types are supported only when listed by the destination API catalog. DNSMigrator does not pass an unknown type through optimistically. Redirect types such as URL, URL301, FRAME, and MXE are treated as provider redirect features when the destination lacks the exact type. Cloudflare redirect/Worker records, Akamai CDN/TLC records, LuaDNS scripts, ClouDNS web redirects, AdGuard Home passthrough entries, and MikroTik forwarding/NXDOMAIN entries are likewise provider-only.

These rows are Unsupported with a note to recreate the feature manually; no target record is emitted. By contrast, SOA, DNSKEY, and apex NS are Managed because the destination provider creates them. Delegated subdomain NS records are ordinary records and can migrate.

Other validation notes include:

• A CNAME with more than one value becomes Review and keeps one target.
• A CNAME sharing an owner with another record becomes Review unless it is an apex CNAME at a flattening provider.
• An unsupported total TXT length becomes Unsupported; content is never silently shortened.

Use Previews and record statuses to turn these rules into a review checklist, then continue to Apply and verify.