Moving a live site behind the network.

We issue you an address for your hostname. Going live is replacing the record that currently points at your origin with one that points at that address. Nothing else about your application changes.

• Lower the TTL first, then wait. Set the existing record to 300 seconds and leave it alone until the old TTL has elapsed. This is the whole difference between a mistake costing five minutes and a mistake costing a day, and a rollback is just as quick as the change.
• At a subdomain, use an A record, plus an AAAA record if we issued you an IPv6 address. A CNAME to the name we give you is equally fine if your provider prefers one.
• At the apex, example.comwith no label, a CNAME is not valid DNS. Use an A record, or your provider’s ALIAS or flattening record if it offers one.
• Leave mail alone. MX records, and the host they name, must keep resolving to your mail server. Point them at the edge and your mail stops.

; before
example.com.        300  IN  A      <your origin address>
www.example.com.    300  IN  CNAME  example.com.

; after
example.com.        300  IN  A      <the address we issue you>
www.example.com.    300  IN  CNAME  example.com.

Before the DNS change, confirm the origin serves the site correctly on its own address with the right Host header. If the site misbehaves afterwards you then already know it was not misbehaving before, which removes the single most time consuming question in an onboarding ticket.

curl -sSI --resolve example.com:443:<your origin address> https://example.com/

Once traffic is flowing through the network, restrict the origin so that it accepts connections only from the network. Do it at the host firewall, and again in the web server if it has an equivalent control, because two layers means a rule reset by a package upgrade does not silently open the door.

Do this step after traffic is flowing, never before. An origin closed while its own DNS record still points at it is a site that is down, and you will be locked out of it alongside everyone else.

We issue and renew certificates for your hostnames automatically, using ACME with HTTP-01 validation. Validation is an ordinary HTTP request on port 80 for a path under /.well-known/acme-challenge/, and the edge answers it itself from an exact token lookup. Nothing is forwarded to your origin for it, so no configuration is needed at your end.

What breaks issuance is the request never arriving. That is the trap, and it is a real one because the symptom is not a warning about security, it is a site that does not load at all on 443.

• Port 80 must reach the edge. Not be redirected somewhere by a device in front of us, not be filtered shut by a network ACL, not be answered by another load balancer that is still in the path. Forcing every visitor onto HTTPS is correct, but that redirect belongs at the edge, not in a rule that makes port 80 unreachable.
• Point the DNS record first, then ask for the certificate. Validation follows the hostname, so a certificate ordered for a name that still resolves elsewhere will fail every time until the name moves.
• Name every hostname you want covered, including www. Certificates are issued per hostname. A wildcard needs a different validation method that the network does not perform, so a wildcard request is one that can only fail.

A site that still works after a DNS change has proved nothing. It works identically whether the change took effect or not, which is why this step exists.

dig +short example.com @1.1.1.1
curl -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://example.com/

• The address in both answers should be the one we issued, not your origin. Query a resolver you do not control, because your own may still be holding the previous answer quite legitimately.
• Load a few pages and watch the request counters for your tenant move. If the site is plainly serving and the counters are flat, the traffic is reaching your origin some other way.
• Then confirm the reverse. Once step two is done, a request sent straight to the origin address should be refused. If it still succeeds, the origin is open and everything above it is ornamental.

Three things make the difference between mitigation taking minutes and mitigation taking most of a day, and all three are on your side of the line.

• Drop the TTL now, before anything else, if you can still reach your DNS provider at all. Every minute of the old TTL is a minute the flood keeps its old destination after you have changed the record.
• Send the facts in the first message: the hostname, the origin address, what you are seeing and when it started, and, most importantly, who is able to change the DNS. Emergencies stall on that last one far more often than on anything technical.
• Do not close the origin yet. Firewalling it while the hostname still resolves to it takes the site down harder than the attack was managing. Close it once traffic is coming through us, as in step two.

Four failure modes account for nearly every onboarding ticket. They all look like the network being broken and none of them are.

The record is changed and the old server is still getting the traffic.

DNS has not propagated. Resolvers are entitled to hold the previous answer for the length of the old TTL, which is exactly why the TTL is lowered a day before the change and not with it. Check from a resolver you do not control. If the old answer outlives the old TTL, the record you edited is usually not the record in use: a separate www entry, or a zone your registrar is not actually serving because the nameservers point somewhere else.

Requests through the network fail with 502 or 504, requests straight to the origin work.

The origin is refusing the network. Either the allow list from step two is missing an address currently in use, or a host based ban tool has banned an edge address by itself for opening a lot of connections from one source, which is precisely what a reverse proxy looks like from the origin. Allow the network’s addresses at the firewall and exclude them from automated banning, otherwise the site will fail again the next time you are busy.

The browser reports too many redirects.

A redirect loop, and it is almost always the origin forcing HTTPS. The node connects to the origin over plain HTTP, the origin sees a plain request and redirects it to HTTPS, the visitor comes back through the node, and the origin does it again. Stop redirecting at the origin and let it read X-Forwarded-Proto instead, which the node sets from the listener that accepted the connection rather than from anything the client claimed.

Certificate issuance keeps failing.

Validation is not reaching us on port 80. Check three things in this order: that the hostname resolves to the address we issued, that port 80 is open the whole way to the edge, and that nothing else in front of the hostname is answering port 80 on its own. A certificate ordered for a hostname that still resolves elsewhere cannot validate, because the validation request follows the hostname.

If your site is serving but a payment callback or a monitoring probe has started failing, that is a different problem with a different fix, and it is the subject of the next page.