DNS migration to Cloudflare: the checklist that avoids three hours of blackouts

DNS migration to Cloudflare has a reputation for being trivial: import the zone, point the nameservers, wait for it to propagate. The teams that were blacked out for three hours followed exactly this script. The problem is that "trivial" describes the perfect case, and production is rarely perfect.

What automatic import doesn't do for you

When you add a domain to Cloudflare, the platform queries the current provider's authoritative servers and attempts to import all records in the zone. The result is a list of records that appears complete—and almost always is. The "almost" is where the risk lies.

TLSA-type records, used for DANE (DNS-named entity authentication), are often not imported. The same happens with some SRV records with non-standard configurations, CAA records with multiple flags or unusual values, and any record that the previous provider serves via a non-standard response. Cloudflare import is a starting point, not a guarantee of loyalty.

The correct protocol is: after import, export the current provider zone in BIND format (most providers offer this) and manually compare the two sets of records. Tools like diff against the exported zone file reveal what the import missed. This step takes twenty minutes and avoids discovering, after the nameservers are turned over, that the email certificate has stopped validating because a TLSA record is missing.

Cloudflare proxy and non-HTTP services

Cloudflare operates in two modes for each A or AAAA record: proxied (traffic passes through Cloudflare's network, the real IP is hidden) and DNS-only (pure resolution, without intermediation). Imported MX records are DNS-only by default, which is correct because SMTP does not go through the Cloudflare proxy.

The problem appears with A records that point to email servers or any service other than HTTP/HTTPS. An A record called mail.exemplo.com that points to the SMTP server can be proxied by accident during configuration, especially if someone is reviewing the records and enabling the batch proxy. The result is that the email server now exposes Cloudflare IPs instead of the real IP, and external SMTP connections reach a proxy that doesn't know what to do with them. The error is not immediate — some email clients try again, the timeout takes minutes, and the problem appears intermittent before becoming consistent.

The same happens with databases exposed via DNS. An A record that resolves to a MySQL or PostgreSQL server behind the proxy returns the Cloudflare IP. The application tries to connect to port 3306 or 5432, the proxy refuses (it does not support these ports by default), and the connection fails with a timeout. The service appears to be down, but the DNS is "working" — it's just pointing to the wrong place.

Before flipping nameservers, review each A and AAAA record and confirm the correct mode. The rule is straightforward: if the service at that address does not respond exclusively in HTTP/HTTPS on ports 80 and 443, the mode must be DNS-only.

TTL and propagation window

Nameserver propagation is not instantaneous, and the TTL of records in the current provider determines how long it takes for resolvers around the world to discard the old cache. If your records have a TTL of 86400 seconds (24 hours) — the standard for many providers — and you turn the nameservers on now, some of the resolvers will continue serving the old records for up to 24 hours, regardless of what Cloudflare already says.

The right strategy starts two days before the migration. Lower the TTL of all critical records to 300 seconds (five minutes) on the current provider. Wait the time equivalent to the original TTL: if the records were at 3600 seconds, wait one hour; if they were at 86400, wait 24 hours. Only then turn on the nameservers. Therefore, when the change happens, caches around the world expire in a maximum of five minutes, and any problems that arise during the migration are resolved quickly — you are not stuck waiting for 24-hour caches to expire while the incident takes place.

This step is the most often ignored because it requires advance planning. Those who arrive the day before the migration and notice that the TTLs are at 86400 have two options: lower the TTL and wait 24 hours before proceeding, or accept the risk of a long propagation window. The second option is the most common path to a blackout that lasts longer than it should.

DNSSEC: the detail that turns propagation into validation failure

If the domain has DNSSEC active at the current provider, migrating the nameservers without handling the DS records at the registrar causes validation failure on all resolvers that check DNSSEC. The resolver receives notice that the domain uses DNSSEC (via the DS record at the registrar), queries Cloudflare, receives signatures signed with Cloudflare keys, and rejects the response because the keys do not match the DS that still points to the previous provider.

The correct sequence has four steps with waiting windows in between. First, remove the DS records from the registrar (not at the DNS provider, at the registrar where the domain is registered). Second, wait for the TTL of DS records to expire—usually between one and four hours, depending on the recorder. Third, flip the nameservers to Cloudflare. Fourth, enable DNSSEC within the Cloudflare dashboard and add the new DS records that the platform provides to the registrar. Skipping the waiting period between the first and third steps is the most common cause of DNSSEC incidents in migrations.

How to structure the migration so as not to improvise under pressure

The difference between a migration that ends in thirty minutes and one that turns into a three-hour incident is almost always organizational. Teams that perform well define in advance who validates each step, what configures rollback, and what the success criteria is before declaring the migration complete.

The operational sequence that works starts with comparing zones between the current provider and Cloudflare, done before any pivot. Domains with SPF, DKIM and DMARC require special attention: TXT records may have quotes or concatenations that automatic import reformats, breaking validation even if the content appears correct. SRV records for services like SIP, XMPP or Minecraft need manual priority and weight field checking.

After the nameservers are turned over, the verification protocol has three commands that must run in sequence. The dig @1.1.1.1 +short exemplo.com NS command confirms that Cloudflare is already authoritative for the domain on that resolver. The dig @8.8.8.8 +short mail.exemplo.com A command verifies that the email log returns the server's real IP, not a Cloudflare IP. A test sending email from an external address within the first thirty minutes of the turnaround closes the basic verification cycle.