How to put a CDN in front of your custom domain, step by step
Putting a CDN in front of your own domain is a short checklist and about four places people trip up. Here is the whole thing in order, including how to undo it.
This is a job that takes about ten minutes of actual work and one day of waiting, and almost everything that goes wrong with it goes wrong because the two got done in the wrong order.
So: the sequence, the things to check before you start, and the four ways it commonly goes sideways.
Before you touch anything
Five minutes of checking here saves an evening later.
- Find out where your DNS is actually managed. Not where you bought the domain — where the nameservers point. These are frequently different, and people spend an hour editing records at a registrar that is not authoritative for anything.
- Note your current record and its TTL. Write down the exact value you are about to change. This is your rollback.
- Check whether you need the apex. Putting
www.example.combehind a CDN is straightforward. Puttingexample.comitself behind one has a complication — see below. - Check for a CAA record. If your domain has one, it lists which certificate authorities may issue for it. If the CDN's authority is not listed, certificate issuance will fail with an error that does not obviously say why.
- Know where your origin will be reachable. The edge has to be able to fetch from it, and if you plan to firewall the origin afterwards, plan that as a later step rather than a simultaneous one.
The sequence
Lower your DNS TTL — a day ahead
Drop the record you will change to 300 seconds. Then wait for the old TTL to expire everywhere, which is why this step happens a day early. Doing it at the same time as the switch accomplishes nothing, because resolvers are still holding the old record with its old lifetime.
Create the zone
Point it at your origin's address or hostname. You get back a CDN hostname you can use for testing.
Test thoroughly on the CDN hostname
Before any DNS changes. Load the homepage, a product page, a form, a logged-in page. Check that images load, that redirects behave, and that anything reading the visitor's IP still sees the right one rather than the edge's.
Add your custom domain to the zone
Register www.example.com with the zone so the edge knows to answer for that hostname and to request a certificate for it.
Change the DNS record
Usually a CNAME from your hostname to the CDN hostname. This is the moment real traffic starts flowing through the edge, and with a 300-second TTL it happens over about five minutes rather than a day.
Wait for the certificate
Issuance normally needs DNS already pointing at the CDN, since validation is performed against the live hostname. Expect minutes, not seconds. Do not panic at a certificate warning in the first few minutes.
Verify, then raise the TTL again
Check the site over HTTPS from more than one network. Confirm cache headers are appearing. Then put the TTL back to something sensible — 3600 or higher.
The apex domain complication
If you want example.com and not just www.example.com on the CDN, you hit a rule in the DNS specification: a CNAME cannot coexist with other records at the same name, and the apex must carry NS records and usually MX records. Putting a CNAME there can break your email.
Three ways out, in order of preference:
Use your DNS provider's flattening feature. Called CNAME flattening, ALIAS or ANAME depending on the provider. It resolves the target behind the scenes and serves an A record, giving you CNAME-like behaviour at the apex without violating anything. This is the right answer if available.
Redirect the apex to www. Keep a plain A record at the apex pointing at something that issues a 301 to www.example.com, and put the CDN on www. Perfectly respectable, and many large sites do exactly this.
Use a static A record. Works, but you now own the problem of updating it if the address ever changes, and you lose the automatic failover a hostname-based record can provide.
The four things that go wrong
Do
- Lower the TTL a day early
- Test on the temporary hostname first
- Check CAA records before expecting a certificate
- Keep the origin reachable during cutover
- Keep your old record written down
Do not
- Switch with a 24-hour TTL still in place
- Firewall the origin before the edge is working
- Put a CNAME at the apex
- Change DNS and origin configuration in one go
- Do it on a Friday afternoon
The most common of these by some distance is the firewall one. It is entirely reasonable to want your origin to accept traffic only from the edge — that is good practice and you should do it. But do it after you have confirmed traffic is flowing through the edge correctly, not before, or you will be debugging a 502 with no way to check whether the origin is even up.
Check what your application sees as the client IP after the switch. Traffic now arrives from the edge, so anything that logs, rate-limits or geolocates by IP will see the edge's address unless it reads the forwarded header instead. Rate limiters are the ones that break most memorably — every visitor appearing to be the same client.
Rolling back
Worth knowing before you need it: the rollback is changing the DNS record back to the value you wrote down, and with a 300-second TTL it takes about five minutes. That is the entire reason for lowering the TTL first — not to make the change fast, but to make the undo fast.
Keep the TTL low for a day or two after the switch for the same reason. Raise it once you are confident.
Frequently asked questions
How do I point my domain to a CDN?
Create a zone at the CDN pointing to your origin, test the site on the temporary hostname the CDN provides, add your custom domain to the zone, then change your DNS record — usually a CNAME from www.example.com to the CDN's hostname. Lower the record's TTL a day beforehand so both the change and any rollback take minutes rather than hours.
Should I use a CNAME or an A record for my CDN?
A CNAME wherever possible, because it lets the CDN change the underlying addresses without you editing anything. The exception is the apex of your domain, where a CNAME is not permitted and can break email delivery. There you need your DNS provider's CNAME flattening or ALIAS feature, a redirect from the apex to www, or a static A record.
How long does it take to switch a domain to a CDN?
The change itself is one DNS record edit. How quickly it takes effect depends on the TTL that was set before you changed it — with a TTL of 300 seconds it propagates in about five minutes, while a 24-hour TTL means some visitors reach the old address for a day. Certificate issuance typically adds a few minutes after DNS is pointing correctly.
Why is my SSL certificate not issuing after pointing DNS at the CDN?
Three common causes. DNS may not yet have propagated, since validation is performed against the live hostname. A CAA record on your domain may not list the certificate authority the CDN uses, which blocks issuance. Or the hostname may not have been added to the zone, so no certificate was requested for it. Check the CAA record first, as its failure mode is the least obvious.
Will my visitors' IP addresses still be visible after adding a CDN?
Your origin will see the edge server's address as the connection source, with the visitor's real address passed in a forwarded header. Anything that logs, geolocates or rate-limits by IP must be configured to read that header, or it will treat all traffic as coming from a handful of addresses. Rate limiters are the most disruptive thing to overlook here.
Done in this order, the public cutover is a non-event: you have already seen the site working through the edge, the DNS change takes five minutes, and if anything is wrong you are five minutes from being back where you started.
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
