Export and document a DNS zone: preserve the source and record the gaps

Define what the export represents

Record the zone, public or private scope, provider, representation type and approved collection method before arranging a later export. Ask which record sets and provider settings the documented method includes. A downloadable file, matching hash or parser success answers a different question from completeness, equivalent features or a successful restoration.

Keep the original in approved protected storage. If it is later obtained under authorization, record its actual collection time and timezone, method, byte length and hash; never invent these fields from an example. Make a separate working copy for edits. Preserve relevant comments and source provenance rather than treating every comment as disposable.

Start with a blank evidence register

Cover: zone/scope reference ____; source provider and dated documentation ____; authorized collector and method ____; actual source time/timezone ____; protected original location, bytes and hash if obtained ____; working-copy reference ____; destination, import mode and current documentation ____; expected set count, individual-record count and exclusions ____. Leave unavailable evidence explicitly unknown.

Sidecar card: feature or authority issue ____; source and destination documentation/date ____; understood, conversion required, unsupported or unknown ____; expected difference ____; responsible owner ____; separately authorized later acceptance criterion and evidence ____. Distinguish a documented expectation from an operation already accepted.

Read source and destination rules separately

Cloudflare’s page, updated April 16, 2026, documents inline comments and exported reserved cf- tags. Its cf-proxied:true and cf-proxied:false tags describe proxied and DNS-only record configuration. On import, a per-record tag takes precedence over the general import selection; without that tag the general selection applies. Preserve this context without assuming another provider interprets it or supplies an equivalent proxy.[2]

That page supports $ORIGIN, $TTL and $GENERATE but not $INCLUDE in its documented import workflow. Azure’s portal guide, updated August 11, 2026, supports $ORIGIN and $TTL but rejects $GENERATE and $INCLUDE. A file suitable for one documented importer is therefore not automatically suitable for another. Recheck the relevant product, mode and current limits before an operation.[2][1]

Azure distinguishes importing while creating a zone from merging into an existing zone. Its documented merge retains existing record-set TTLs in the ordinary case; a CNAME can replace an existing CNAME, while conflicts with another record type retain the existing record. SOA host and apex NS data remain provider-owned; the guide treats their import behavior separately from other SOA parameters and the apex NS TTL. TXT string structure may also differ. These are scoped conversion questions, not evidence of a completed restore.[1]

Fictional Copper Lantern Archive: count the missing evidence

Four represented + one provider-specific + one unknown = six expected inventory rows. Four + one = five source-present sets; six − five = one missing set. These are record-set counts, not file lines or individual-record totals. SOA and apex NS are deliberately excluded here and recorded separately below. The placeholders are not valid deployable addresses, SPF policies or verification values.

Separate unresolved gaps from authority expectations

G1: R3’s text is present, but destination proxy semantics remain unresolved. A CNAME row alone does not establish feature equivalence. G2: R6 is missing from the described source; its owner note identifies an evidence need, not a value authorized for publication. Lena must obtain approved coverage evidence and a destination-feature decision. Two unresolved gaps mean HOLD for completeness and exact-feature claims.

A1: SOA host is provider-owned. A2: apex NS data is provider-owned. These are two documented destination conversion expectations, outside the six-set application/mail count; neither is an extra missing row or a completed conversion. Delegation changes belong to their separately authorized plan. The file cannot establish mail continuity or website readiness.[1]

Define the later acceptance question

Before any separately authorized import, record destination product/mode, new-zone or merge behavior, relevant directive and size limits, conflicts, required conversions and what later evidence each owner will accept. A preserved file and hash identify bytes; parser acceptance addresses syntax in that context. Neither closes G1/G2, proves authority or demonstrates working mail, proxy behavior and services.

Do not label the package a full account backup. Accounts, credentials, private keys and service configuration require their own approved recovery arrangements. Document which settings are represented or referenced; do not assume every export omits every feature, or that any single export includes them all.

Hand over a qualified documentation decision

Deliver the untouched source reference, separate inventory, feature/authority sidecar, exclusions, unresolved owners and later acceptance criteria. Mark each issue documented, held for evidence or accepted only with dated supporting evidence. In this fictional case the outcome remains HOLD, not permission to import. Keep the cutover sequence, mail dependency review and TTL timing decision in their linked guides.