DNS cutover and rollback

What changes at cutover

The origin stays where it is. You named that host when you added the site. CloudFront fetches it. Visitors keep the same URL. The certificate visitors see is the one on the edge. The origin keeps its own certificate for the hop from CloudFront.

Two setups exist. CNAME mode is the default: one hostname that is not the zone apex gets a CNAME to the CloudFront target on the go-live panel. Managed DNS is the other: you import mail and verification records into our zone, then change nameservers at the registrar. We already wrote the SSL validation CNAMEs and an alias A record for the apex and www inside that zone. Those aliases are not what the world sees until the nameservers change.

A distribution we create does not cache. A request is forwarded to the origin, so rolling DNS back does not leave a cached copy of the site on that edge. HTTP is redirected to HTTPS at CloudFront. An edge that was already running and later attached by an operator can still have its own cache settings. Attaching it does not create a second distribution and does not change your DNS.

Rules start in count. After 24 hours, your dashboard shows what's safe to block — one click. You still click Promote. Nothing is blocked automatically. Cutover does not click Promote. The Protections list is where you see Count. Leave it on Count while you change DNS. Switching a row to Block is a separate click, and it applies immediately.

A response-headers policy on the distribution adds a baseline of security headers and removes the origin Server and X-Powered-By headers. Those security headers are not proof that traffic is on CloudFront. An origin can send the same names.

Before you change DNS

Save your current records first. Write down the type, name, value, and TTL of anything you will change. We do not keep a copy.

1. Lower the TTL on the record you will replace, at your DNS host, if it is long. Many hosts default to hours. Set it down (300 seconds is a common short value), then wait out the old TTL once so caches learn the short one. We do not read your TTL and we do not change it.
2. Confirm the shield is up and still in count. On the site page the Shield row says WAF and CloudFront are up before the traffic record is the step. Open Protections and check that each group that is on says Count. The default groups are created in count. Nothing on the go-live panel changes that.
3. Write down every record you might replace: type, name, value, and TTL. For managed DNS, also write down the nameservers that answer today (`dig +short NS` on the zone). A screenshot or the zone export from your DNS host is the rollback copy.
4. For managed DNS, import mail before you touch nameservers. The checklist on the site page is the product's order.

Managed DNS, in the order the site page shows:

1. Import MX, TXT, and mail hosts first. Scan current DNS, try a zone transfer, or paste a BIND zone file. Add anything the scan misses by hand. Those records sit in our zone now — they are not public until you switch nameservers.
2. Confirm mail and verification will survive. You need MX plus TXT for SPF, DKIM, and DMARC if you send mail or verify Google/Microsoft. Without them, mail and those checks break the moment nameservers change. Imported records are what stay live.
3. Change nameservers at the registrar last. Paste the four nameservers we list. Do this at the registrar (where you renew the domain), not in a DNS-records tab. We already wrote SSL and CloudFront traffic records.

The import is how mail can survive a nameserver switch. It is not a backup. A live scan can miss names. A zone transfer often returns nothing. The zone file you upload is only as complete as the file. The rollback copy is the one you saved at the current host, and that host's zone has to still exist if you point nameservers back.

Route 53

If you keep your own hosted zone, we do not call the Route 53 API. You edit the zone. The go-live panel shows the type, name, and value.

1. For a name that is not the apex (www, or another hostname): create a CNAME. The name is the host on the panel. The value is the CloudFront hostname in the Value column, a name ending in cloudfront.net.
2. The zone apex cannot be a CNAME. Route 53 will not save one. To put the apex on the shield in your own zone, create an A record and turn on Alias, aimed at that same CloudFront hostname. Alias is not a CNAME, and it does not have a TTL you set. Or switch this site to managed DNS and we write the alias in our zone.
3. Delete or stop using the old A or AAAA for that same name only after you have written it down. A CNAME cannot sit next to those records.
4. Save. Then use the checks below. Recheck on the site page.

If the site is managed DNS, you do not create that alias yourself. We write an alias A record for the hostname on the site and for www in front of that hostname, aimed at the distribution. Validation CNAMEs in that zone use a TTL of 300 seconds. You change nameservers at the registrar last, to the four we list. Changing them inside a record editor does not delegate the domain.

Cloudflare, DNS only

The traffic CNAME and the SSL validation CNAME have to resolve to us. Cloudflare's proxy (orange cloud) hides the target, and the addresses are Cloudflare's, so the checker will not call the hostname live. The record stays DNS only (grey cloud).

Connect DNS in one click (Cloudflare or GoDaddy), or we can do concierge DNS (~one business day). One-click publish is a button on the go-live panel after you save a Cloudflare API token on Account. The token scope is Zone DNS Edit and Zone Read. The click sends the CNAME and TXT rows we show (SSL validation and the traffic record). It creates the record, or updates the first record of that same type and name. CNAMEs are sent with proxy off.

TTL on that publish is automatic. Cloudflare's API uses 1 for automatic, which is not a one-second TTL. The publish does not read the old TTL and does not shorten it first. It does not store the previous value. It does not delete an A or AAAA at that name, so remove those yourself after you have saved them, or the CNAME cannot coexist with them. It does not change nameservers.

1. In Cloudflare, open the zone, DNS, Records.
2. Add a CNAME. Name is the host label (www, or the validation name). Target is the value we show. Proxy status is DNS only.
3. If you use the one-click button instead, it does that proxy setting for the rows it writes. Other records in the zone are untouched.
4. Orange cloud on the traffic name sends visitors to Cloudflare, not to CloudFront. Turn it off for that record.

GoDaddy, Namecheap, and other hosts

Point your domain with the records we show. We'll confirm when the shield is live. Saved API credentials exist only for Cloudflare and GoDaddy. Namecheap, Google, IONOS, Bluehost, DNSimple, Hover, and anyone else get the same record table and help text when we recognize the nameservers. Recognizing a nameserver does not connect an API.

GoDaddy one-click is the same button idea. It writes each CNAME or TXT we show with PUT, which replaces every record of that type and name with the single value we send, at TTL 600 seconds. It does not keep the previous data. It does not replace an A record when the row we send is a CNAME. It does not create the apex URL forward.

1. GoDaddy: DNS, Records. Add a CNAME. Host is the left label (www, or the validation host). Points to is the target we show. Save the old record before you replace it.
2. Namecheap: Advanced DNS, add a CNAME. Host is the left label. Value is the target we show. There is no Namecheap connection in the product.
3. Anyone else: create the row in the table on the site page. Type, name, and value are the three columns. Copy on the panel is those three fields on one line.
4. Apex forwarding (GoDaddy URL forward, Namecheap redirect, and the same idea elsewhere) is how the root can send people to www. We do not create that forward.

Concierge is a request from the dashboard. The page says a specialist will email you within one business day. That email is not the cutover. DNS changes when someone edits the zone.

Apex and www

A CNAME cannot sit on the zone apex at most DNS hosts. If you type an apex and leave the site on CNAME, we store www instead and protect that name with one CNAME. The site page can suggest an optional redirect from the apex to www. You add that redirect at the registrar. We do not.

Cloudflare can flatten a CNAME at the apex. Keep it DNS only if you use that. Our default CNAME setup still stores www when you typed the apex, so the record we show is www unless you chose managed DNS.

Route 53 alias and DNSimple ALIAS are the usual way to put an apex on CloudFront without a CNAME. The help text says so when we recognize those nameservers. We write the alias only in a zone we host (managed DNS), for the apex and www. In your own Route 53 zone, you create the alias. The checker treats it as live when the hostname's A records overlap the distribution's A records, which is what an alias or a flattened CNAME looks like. `dig CNAME` is empty in that case.

Managed DNS delegation replaces the public zone with ours. Only the records you imported, plus the SSL CNAMEs and the traffic aliases we wrote, are what answers after the switch. Mail that was never imported stops. That is why the checklist says import first and change nameservers last.

How to verify

Substitute your hostname and the CloudFront target from the go-live panel. The target is the Value on the traffic row, a name ending in cloudfront.net. The commands below are the same signals the dashboard uses, plus the response headers CloudFront adds.

On a distribution we create, x-cache is often Miss from cloudfront, because that distribution does not cache. A miss still means CloudFront answered. You may also see a Server header of CloudFront. That is the edge, not your origin's version string. The origin Server and X-Powered-By headers are removed.

Do not use the security headers alone. Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy are added by our header policy, and an origin can send headers with those names too.

There is no header for count mode. A 200 is what a normal page does in count, and it is also what a normal page does if a rule is in block and did not match. A 403 is what a visitor can see after you have promoted a rule. It is not what cutover looks like. Confirm Count on Protections.

Recheck on the site page is the product's check. It polls on its own. We couldn't reach the checker. Try again, or wait — this tab re-checks on its own. A result that is not a match is not reported as a match. When DNS matches and requests show up, the state is Live — traffic is flowing, and the detail says rules are in count. When DNS matches and the published series has no requests, the state is Live — no traffic yet. Open the site in a browser, then recheck. A missing series is not confirmed, and it is not zero.

Rollback

Use the copy you saved. Put the same type, name, value, and TTL back at the DNS host that was authoritative before the change.

• CNAME mode: restore the previous record for that hostname. If you had replaced an A or AAAA with the CloudFront CNAME, put that A or AAAA back and remove the CNAME. One-click has no undo. Clicking it again writes our target again.
• GoDaddy one-click wrote TTL 600 on the new record. Resolvers that cached it keep the CloudFront answer until that TTL expires. The TTL that matters for the first change was the old one you lowered.
• Cloudflare one-click used automatic TTL and left the proxy off. Grey-cloud is what you want if you publish again later. For rollback, restore the saved record and the proxy state you actually had.
• Managed DNS: at the registrar, set the nameservers back to the ones you wrote down. The previous host's zone has to still be there. We do not keep it, and we do not change registrar nameservers. Imported rows in our zone are not pushed back to the old host.
• After DNS points away, Recheck shows waiting for DNS again. We do not delete the distribution, the certificate, or the WebACL because you rolled DNS back. Removing the site is the danger-zone action, and that card already says to point DNS back first.
• WAF mode does not change. If you had already clicked Promote, undo is still a separate click that sets that rule back to count. DNS rollback does not promote, and it does not undo.

Expected propagation for a host record is the TTL of the answer resolvers cached. Before the cutover, that is the old TTL, which is why you lower it and wait it out once. After the cutover, a rollback waits out the TTL of the CloudFront record they cached. We do not flush public resolvers. Nameserver rollback is slower and is not that host-record TTL. The parent zone's NS TTL is what caches hold, and the product does not display one number for it. The go-live panel re-reads public NS and will say when it cannot read them yet.

What we do and do not do

We create the certificate, the WebACL in count, and the CloudFront distribution. We show the DNS rows. We recheck. For Cloudflare and GoDaddy, one click can publish the CNAME and TXT we show, after you connect credentials and click. For managed DNS, we write validation CNAMEs and the apex and www aliases into our zone before you delegate. A concierge request sends you to a person. The dashboard says that person emails within one business day.

• We do not change DNS until you add the record, click publish, or change nameservers.
• We do not lower TTL.
• We do not store the records you replace, and we do not restore them.
• We do not create the apex-to-www redirect.
• We do not connect a DNS API except Cloudflare and GoDaddy, and only for the CNAME and TXT rows we show.
• We do not flip any rule to block because DNS moved. Promote stays a click.
• We do not take the edge down because DNS moved away.
• An operator can attach our WebACL to a CloudFront distribution that already exists. That path does not create a second distribution, and it returns the previous WebACL so the attachment can be reversed by an operator. It does not change customer DNS, and it is not a button on the go-live panel.

Answers

Related guides

• Managed WAF setup: DNS cutover to count
• Concierge DNS
• What is WAF count mode?

More in this section

• Onboarding
• Failure states
• DNS and platforms