BIND zone files

A BIND zone file migration in DNSMigrator can use a file as the source, download translated records, or normalize files in the web tools and CLI. The parser supports a deliberate subset centered on $ORIGIN and $TTL, and reports or skips data it cannot represent instead of following other directives or preserving provider-only behavior.

How a BIND zone file migration works#

If you still need the source file, follow the provider-specific steps in How to export a DNS zone file before validating it here.

To use a file as the destination, start from a connected provider and choose Zone file under Where is it going? The preview is free. Select Download zone file; nothing is applied to a provider.

The same Download zone file action is available on any migration with a preview. It serializes the translated target for that migration’s selected destination, not a raw source backup.

Minimal accepted file#

Use an explicit, fully qualified origin and a default TTL:

$ORIGIN example.com.
$TTL 1h

@ IN SOA ns1.example.net. hostmaster.example.com. (
  2026092701 ; serial
  7200       ; refresh
  3600       ; retry
  1209600    ; expire
  300        ; negative cache
)
@                 IN NS    ns1.example.net.
@                 IN NS    ns2.example.net.
@          300    IN A     192.0.2.10
www               IN CNAME @
@                 IN MX    10 mail.example.net.
@                 IN TXT   "v=spf1 include:_spf.example.net -all"
selector._domainkey IN TXT ( "v=DKIM1; k=rsa; p=first-part"
                             "second-part" )
_sip._tcp          IN SRV   10 5 5060 sip.example.com.

Paste a file into the explainer to decode owners, TTLs, record types, and fields line by line. The BIND zone file format guide explains the underlying syntax in more detail.

Semicolons begin comments outside quoted strings. Parentheses join physical lines into one logical record. A line that begins with whitespace inherits the previous owner. Relative owner names are resolved under $ORIGIN; @ means the origin.

The parser can infer an origin from an absolute SOA owner when no $ORIGIN appeared yet. The CLI also accepts --origin <domain>. For predictable files, prefer an explicit $ORIGIN.

Supported directives#

Unsupported directives produce a line-numbered error and are not executed. Expand generated records and paste included content into one reviewed file before validation.

Supported and ignored record types#

The parser accepts these types:

RRSIG, NSEC, NSEC3, NSEC3PARAM, CDS, and CDNSKEY are silently ignored by the BIND parser. DNSKEY is parsed, but migration translation marks it Managed because the destination signer supplies its own key. An unknown type, including an unlisted TYPE#### presentation, is reported as an error and skipped.

Support in the parser does not imply support at every destination. The translation engine checks the selected provider’s API catalog after parsing. For example, a valid TLSA record can still be Unsupported at a destination whose adapter does not declare TLSA. Compare providers under Supported providers.

TTL and owner rules#

For each record, effective TTL is selected in this order:

1. A TTL written on that record.
2. The current $TTL default.
3. The last explicit per-record TTL.
4. 3,600 seconds.

If there was no $TTL, parsing an SOA can set the default from its minimum field for later records. TTLs normalize to nonnegative integers in the canonical model and are later clamped to destination limits. See Translation rules.

Classes IN, CH, HS, and CS are recognized in the record preamble, but the canonical record model does not retain a class. DNSMigrator’s migration output is written as IN; do not use this workflow to preserve non-IN zone semantics.

The parser qualifies relative RDATA hostnames for CNAME, NS, PTR, ALIAS, DNAME, RP, MX, SRV, and SOA. Use fully qualified names with a trailing dot in other structured RDATA, including HTTPS/SVCB targets, to avoid ambiguity.

TXT strings#

Adjacent quoted strings form one logical TXT or SPF value. Parsing removes presentation quotes and joins the character strings. Serialization escapes backslashes and quotes, then splits one logical value into quoted segments of at most 255 characters:

selector._domainkey 300 IN TXT "first logical segment" "continued segment"

That split does not create multiple TXT records. The destination’s separate maximum logical-value length is still enforced; over-limit values become Unsupported instead of being truncated. Read TXT and SPF translation and Move DNS without losing email before moving long DKIM keys.

Errors and limits#

A web migration source is limited to 2,000,000 UTF-8 bytes by the service. Files above that limit are rejected as larger than 2 MB. The parser reports one-based source line numbers; whole-file errors such as oversize input use line 0.

Reported conditions include:

• No owner name or no usable origin.
• Missing type or record data.
• Unknown record type.
• Invalid $TTL values.
• Unterminated quoted strings.
• Unclosed parentheses.
• Unsupported directives such as $INCLUDE.

The parser can return valid records and errors together. The migration workflow proceeds if it has a zone name and at least one record, so “preview ready” does not mean every line was accepted. Use --strict in the CLI or fix every validator finding when silent omission would be unsafe.

Serialization and loss#

Downloaded files start with $ORIGIN, $TTL 3600, and then sorted records with explicit per-record TTLs. TXT and SPF data is quoted. A header records the zone, selected destination, generation time, and the fact that unsupported records were omitted.

Provider aliases with no ordinary values cannot be represented faithfully in a zone file. The serializer writes a comment such as:

; @ A alias → d111111abcdef8.cloudfront.net. (alias records can't be expressed in a zone file)

That comment is not a working record. Likewise, proxy flags, routing policies, redirect rules, health checks, and other provider metadata are not BIND records. Prefer a provider-specific destination preview when preserving those features matters.

DNSSEC and provider features#

Do not copy source RRSIG, denial-of-existence chains, or DNSKEY material to a managed destination. The new provider signs with its own key, and the parent DS must be changed in the order described by DNSSEC transitions.

A BIND file carries DNS presentation data, not provider intent. Use an API connection when you need proxy state, provider-resource aliases, routing policy, redirect rules, or other settings that the file cannot represent.

CLI workflows#

The open-source CLI reads local files or - for standard input and never asks for provider credentials:

npx dnsmigrator export example.com.zone --format bind --out normalized.zone

npx dnsmigrator translate example.com.zone \
  --to cloudflare \
  --out cloudflare.zone \
  --report translation.json \
  --strict

npx dnsmigrator diff before.zone after.zone --strict

export can produce bind, json, or DNSControl dnsconfig output. translate applies provider limits and appends unsupported source rows as comments after the generated zone, unlike the web download, which only states that unsupported rows were omitted. diff ignores SOA, DNSKEY, and apex NS because hosts manage them.

Use --origin example.com for a file without $ORIGIN, --json for machine-readable command output, and the CLI command reference for all flags.

BIND zone file questions#