Setting up DNS via Cloudflare: migration, DNSSEC, Terraform automation

Configuring Cloudflare DNS: what breaks when migrating zones

Moving a zone to Cloudflare looks like copying a list of records — in reality, the link between the zone contents and delegation breaks.

Some records do not make it into the new set: MX, service TXT records, and subdomain records that only the previous administrator remembered are typically lost.

The old TTL keeps the previous addresses at providers, the new zone serial number has not yet propagated through caches — and different users get different answers to the same query.

Delegation errors are a separate story. If NS is switched at the registrar before the zone is served authoritatively, the addresses point to a server where the data does not yet exist, and name resolution failure looks like domain unavailability with formally “correct” settings.

Nearby is the DNSSEC trap: the DS record remains from the previous zone, signatures do not match, and the site stops opening even where the cache was still returning the correct address.

The cost of such a failure is service downtime, not inconvenience: email does not work, login to the customer portal, payments, and data exchange with external systems fail.

A partial failure is worse than a complete one: some clients are served, some are not, and in the logs this looks like random failures without a common cause.

Configuring DNS through Cloudflare removes most of these risks if the order of steps is verified.

First, we export and reconcile the full set of records, then prepare the zone and check responses from different points, only then switch delegation, and carry out further changes through configuration rather than manually in the panel. Let's break down how this is covered.

What a managed zone provides: response speed and fewer failures

A managed zone is when the DNS state is described by configuration rather than living in the administrator's memory and being edited manually in the panel.

Every change goes through review: you can see exactly what changed and why, and rollback returns the previous zone state in full.

Manual edits, because of which the zone diverges from the real infrastructure, disappear as a class — this is the main effect of configuring DNS in Cloudflare through zone description.

Name resolution response relies on a distributed network: the answer is served by the Cloudflare node closest to the user, not by a single server in one region.

Caching is configured deliberately — a short TTL on records involved in switches and a long one on static records such as MX. Switching a service between locations takes minutes, not hours of waiting for provider caches to expire.

What changes in measurable terms: record switch time — minutes; share of manual edits — zero; class of eliminated failures — a forgotten record after migration, a test host left in the production environment, a conflict between two administrators changing the zone at the same time.

The zone is signed with DNSSEC, keys are rotated according to the policy, so resolver response spoofing stops being a scenario learned about from complaints.

Service availability stops depending on whether someone remembers a specific record. The zone lives alongside infrastructure code: a change arrives together with the other resources, not as a separate task in someone else's queue.

Ways to manage a Cloudflare zone: panel, templates, your own server

A managed zone on the provider side, your own name servers, or a combination of both — the choice is determined by who changes records and how often, how many zones are in the environment, and whether full control over delegation is needed. Below are four modes found in practice, with their applicability and limitations.

All of them are compatible with each other: delegation is switched separately for each domain, while records can live in configuration templates. The task is to understand in advance where management completeness ends and manual work begins, accumulating discrepancies.

In practice, most teams arrive at a hybrid scheme: the zone remains in a managed environment with templates and change history, while domains with their own name servers are connected selectively. We describe such a scheme before work begins — together with the delegation rollback procedure.

Zone migration stages: audit, scheme, edits, verification

From inventory to support — six steps that we perform in a fixed order. The key rule: the new zone is fully ready and verified before NS records are changed at the registrar, so there is always somewhere to return to.

1. Record audit. We export the current zone in full and reconcile it with actual traffic: which names actually respond, where duplicates and long CNAME chains are, and which records have an inflated TTL. Dead records are marked — some of them are discovered only from resolver logs.
2. Zone scheme. We assemble the target structure: subdomain delegation, mail records, service and verification names. The scheme is approved before edits — changing it later is more expensive.
3. Preparing the target zone. We create the zone in Cloudflare, transfer records according to the scheme, and describe the state with configuration so that changes go through review rather than manually in the panel. DNSSEC is configured but not activated until delegation.
4. Verification on the test environment. We run names through independent resolvers, check responses for mail and internal services, and compare the record set with the audit.
5. Switching and verifying delegation. We lower TTL in advance, change NS at the registrar, and confirm delegation from external points. We check the DNSSEC signature chain separately — an error here breaks name resolution entirely.
6. Rollback plan. We save a copy of the original zone and the previous NS: returning takes minutes and does not require restoration from backup.
7. Handover to support. We provide the repository with the zone description, access, change policy, and name resolution failure monitoring.

What we hand over: zone configurations and policies

We hand over not access to the control panel, but the zone itself and the rules by which it is changed without us. The package is designed so that a new engineer on the customer's team can understand the configuration and make an edit without looking into the message history.

• Zone scheme — a map of domains and subdomains indicating where the zone is served, which records are delegated to an external provider and which live on your own servers, and how delegation works.
• Record matrix — a table for each type (A, AAAA, CNAME, MX, TXT, CAA, SRV): purpose, owner, time to live, and the "changes only through the repository" flag.
• Configuration as code description — which records are declared declaratively, what was imported from the existing zone, where state is stored, and how the plan check is run before applying.
• Access roles and keys — separation of read and change permissions, token scoping to specific zones, rotation procedure, and a separate account for automation instead of shared logins.
• DNSSEC procedure — where signing keys are stored, how the delegation record is published at the registrar, what to do during rotation, and how to remove the signature if the chain breaks.
• Change policy — request, verification on the test zone, application plan, maintenance window, rollback point, and the list of people who approve the edit.
• Team instructions — walkthroughs of typical tasks, record propagation diagnostics, unlocking, and where to look when the repository and the live zone diverge.

Acceptance is based on a run-through: a change is applied to the test zone, the signature chain and name resolution from several points are checked, then any discrepancy between the repository and the working zone is recorded.

After that, the configurations remain with you as a working document — with them, the zone can be developed by your own team or handed to another contractor without rebuilding.

Case study: migrating forty zones without service downtime

Starting point

A fleet of forty zones lived in a web panel and was edited manually: records were added directly, change history was not preserved, and the cause of a broken route was reconstructed from message history.

TTL was set to one day, so switching to a backup node stretched up to 24 hours — some clients continued going to a non-working address. Over a quarter, seven incidents accumulated, five of them typos in NS and CNAME records that no one checked before publication.

What we changed and what we got

Zones were described declaratively: a module for each zone, state in remote storage with locking, any change only through review. During migration, TTL was lowered to 300 seconds, DNSSEC was enabled, and a DS record was published at the registrar.

Before changing NS servers, we took a full zone dump and compared it with the reference: a discrepancy in any record blocked the switch.

Metrics after migration: record switch time — from one day to five minutes, rollback — return to the previous state in a minute, share of changes that passed automated verification — one hundred percent.

Post-migration verification walks through all zones: authoritative server responses are compared with the configuration, and there are no false DNSSEC triggers. Failures caused by manual edits — zero over the entire operation period.

How a managed zone differs from your own server

A managed zone is when authoritative name servers live on the provider's network, and the zone contents remain your responsibility. Your own server means you run the service itself: updates, fault tolerance, protection from spikes, and key rotation.

In practice, the choice is between three schemes — they differ in who is responsible for response during a failure and how many people need to be kept on support.

A managed zone scales more easily: requests are spread across a network of points of presence, and growth in the number of requests almost does not change response time.

Your own server requires calculation — how many requests per second an instance can handle, whether there is a second node in another network, and how the service will behave under a reflected attack.

A managed zone also requires work from the team: records, TTL, and the DNSSEC chain with key rotation must be maintained as code, through Terraform and edit review, not manually in the panel.

Your own server adds package updates, monitoring responses from external points, and control over whether the replica matches the source.

The boundaries should be recorded in writing: an error in a record value brings the service down equally in both schemes — the only difference is who is on duty.

Technical doubts: delegation, DNSSEC, rollback

A zone migration rests on three questions: how domain delegation will go, what will happen to protection against response spoofing, and how to return everything back. Below are the answers most often needed by an engineer before work starts.

What does DNSSEC provide, and will it break the domain?

DNSSEC is protection against response spoofing: the zone is signed, and a DS record is published at the registrar. The order is fundamental — first we check validation on public resolvers, then we commit the chain; an erroneous DS makes the domain unavailable to some users.

Will zone backups remain?

Before every change, we export the zone and store version history in the repository. Zone backups are kept outside the provider panel — restoration does not depend on account access, and the previous state can be brought up even months later.

How does change rollback work?

The configuration is described declaratively, so rollback is returning to the previous version and reapplying it, not manually editing records. After that, we compare responses for control names and wait for cache divergence: the operation takes minutes, not hours.

Let's discuss your task: where to start

To discuss the task concretely, it is enough to describe it in your own words and attach what you already have at hand. Then we will review the current state of the zone, ask clarifying questions, and come back with a timeline estimate and a staged work plan.

• Domain and registrar: where the zones are delegated, who owns the account and can change NS records.
• Export of the current zone: critical subdomains, mail records, services that verify the domain via TXT records.
• What is already automated and what is edited manually — this determines the scope of moving the zone to Terraform templates.
• Known problems: whether there have been name resolution failures, mail complaints, manual edits outside working hours.
• Constraints: migration window, acceptable service unavailability time, who confirms the switch and rollback.
• Access and data: rights to the zone in Cloudflare and the registrar panel; transmit tokens through a secrets manager, not in messages.
• Who on the customer side accepts the result and stays in touch if the previous settings need to be restored.

In response, we send a staged work plan, timeline estimate, team composition with roles, and a list of accesses needed at each step. If, based on the review, it turns out that part of the zone is safer left as is, we will say so directly.