Your site loads in under a second for visitors in your data center city. For someone in Singapore, Tokyo, or São Paulo, that same page might take four seconds to render — and four seconds is an eternity. A Content Delivery Network (CDN) fixes this by caching your assets across dozens of edge locations worldwide, but the whole thing is wired together through DNS. Get the DNS configuration wrong and you either break your site entirely or bypass the CDN altogether, defeating its purpose. This guide walks through every DNS step required to put a CDN in front of your site, using real record examples, common pitfalls, and verification commands so you know the traffic is actually flowing through the edge network.
What a CDN Actually Does at the DNS Level
Most people think of a CDN as a caching layer, and that is true — but from a networking perspective, a CDN is a DNS-based traffic redirection system. When a visitor's browser resolves your domain, DNS returns an IP address that belongs to the CDN's nearest edge node rather than your origin server. The browser connects to that edge node, which either serves a cached copy or fetches the content from your origin on the visitor's behalf.
There are two common models:
- CNAME delegation: You point your hostname at a CDN-provided hostname using a CNAME record. The CDN's own DNS infrastructure then resolves that hostname to the optimal edge IP based on the visitor's geographic location. This is the most common setup for subdomains like www or assets.
- Full proxy / nameserver delegation: Providers like Cloudflare ask you to change your authoritative nameservers entirely. All DNS queries for your zone go through the CDN's resolvers, giving them full control over routing, including at the root apex (@).
Understanding which model your CDN uses dictates which DNS records you create and where you create them.
Before You Start — Gather These Details
Rushing into DNS edits without the right information is how sites go down. Before touching any record, collect the following:
- Your origin server's IP address (the server that actually hosts your files).
- Your CDN account's assigned CNAME target or nameservers — this is shown in your CDN dashboard after you add a site or property.
- Your domain's current DNS TTL values. If they are set to 3600 seconds (1 hour) or higher, lower them to 300 seconds at least 24 hours before you make the switch. This reduces rollback time if something goes wrong.
- The hostnames you want to accelerate. Most setups cover www.yourdomain.com and a static assets subdomain like cdn.yourdomain.com or assets.yourdomain.com.
Option A — CNAME-Based CDN Setup (Fastly, AWS CloudFront, Bunny CDN, KeyCDN)
This method works for any CDN that gives you a CNAME target instead of nameservers. The examples below use generic placeholders but reflect the exact format each provider uses.
Step 1: Create a Pull Zone or Distribution
Log into your CDN provider and create a new pull zone or distribution. During setup you will be asked for your origin URL or IP. Enter your server's IP or hostname here. After saving, the CDN dashboard will display a hostname that looks something like this:
Copy this hostname exactly. This is your CNAME target.
Step 2: Create the CNAME Record in Your DNS Zone
Log into your DNS provider (Cloudflare, Route 53, GoDaddy, Namecheap, Porkbun — wherever your authoritative DNS lives). Navigate to the DNS management panel for your domain and create a new record:
If you are routing a dedicated static assets subdomain, add a second record:
Save both records. Note that you cannot put a CNAME on the root apex (@ or yourdomain.com without a subdomain) in standard DNS. If your CDN requires apex coverage, use Option B below, or check whether your DNS provider supports CNAME flattening (also called ANAME or ALIAS records).
Step 3: Verify the CNAME Resolves Correctly
Wait a few minutes for TTL to expire across resolvers, then check from the command line:
On Windows, use:
You should see the CDN's hostname appear in the answer. If you still see your old record, either DNS has not propagated yet or the old TTL has not expired at your resolver.
Option B — Full Nameserver Delegation (Cloudflare, Imperva, Akamai Edge DNS)
Some CDN providers, Cloudflare being the most prominent, work by becoming your authoritative nameserver. This gives the CDN complete visibility into all your DNS queries and lets it apply its proxy, DDoS protection, and WAF at the DNS layer.
Step 1: Add Your Site in the CDN Dashboard
Sign into Cloudflare (or equivalent), click Add a Site, and enter your root domain. The platform will scan your existing DNS records and import them automatically. Review these records carefully — missing a mail record here means your email breaks the moment you switch over.
Step 2: Update Your Registrar's Nameservers
The CDN dashboard will give you two nameservers to use. They look like:
Log into your domain registrar (Namecheap, GoDaddy, Google Domains, Porkbun, etc.) and navigate to the nameserver settings for your domain. Replace the existing nameservers with the two provided by your CDN. Registrar nameserver changes can take anywhere from a few minutes to 48 hours to propagate globally, though most complete within two hours.
Step 3: Enable the Proxy in DNS Settings
Back in the CDN dashboard, look at each DNS record. In Cloudflare, there is an orange cloud icon next to each record. When that cloud is orange (proxied), traffic flows through Cloudflare's network. When it is grey (DNS only), the record resolves directly to your origin. For any hostname you want the CDN to accelerate and protect, make sure the proxy is enabled.
SSL and HTTPS Configuration
Routing traffic through a CDN introduces a two-leg TLS model: one TLS connection between the visitor and the CDN edge, and a second TLS connection between the CDN edge and your origin server. You need to configure both.
- Edge certificate (visitor to CDN): Most CDN providers issue this automatically once your CNAME or nameservers are active. Cloudflare calls this a Universal Certificate. CloudFront uses AWS Certificate Manager. Allow up to 15 minutes after DNS propagation for this certificate to provision.
- Origin certificate (CDN to your server): Your origin server still needs a valid TLS certificate. In full-proxy setups, Cloudflare offers an Origin CA certificate you can install on your server. Alternatively, keep a standard Let's Encrypt certificate on the origin. Configure the CDN's SSL mode to Full (Strict) or equivalent to enforce certificate validation on the origin leg.
Avoid setting the SSL mode to Flexible unless you have no choice. Flexible SSL means the CDN connects to your origin over plain HTTP, which is insecure and can cause redirect loops if your origin also forces HTTPS.
Configuring Cache Behavior and Cache Headers
DNS gets traffic to the CDN, but cache headers tell the CDN what to store and for how long. Without proper headers, you either end up with a CDN that caches nothing (acting as a slow reverse proxy) or one that caches dynamic pages incorrectly (serving stale logged-in content to random visitors).
Key headers to set on your origin responses:
- Cache-Control: public, max-age=31536000, immutable — for static assets with content-hashed filenames (JS, CSS, images).
- Cache-Control: no-store — for authenticated pages, shopping carts, and anything user-specific.
- Vary: Accept-Encoding — tells caches to store separate copies for gzip and brotli compressed responses.
- Surrogate-Control or CDN-Cache-Control — some CDNs respect these headers to set CDN TTL independently of browser TTL.
How to Verify Traffic Is Flowing Through the CDN
Creating DNS records is not the same as confirming CDN traffic. Use these methods to verify end-to-end:
Check Response Headers with curl
A HIT status confirms the response came from a cached edge node. A MISS on the first request is normal — the edge node fetched from your origin and is now caching the response for subsequent requests.
Confirm the Resolving IP Is a CDN Edge Node
You can also use the DNS Lookup tool to query your domain from multiple resolver perspectives and confirm all of them return CDN-owned IP addresses rather than your origin IP.
Common Problems and How to Fix Them
CNAME on Root Apex Fails
Standard DNS does not allow a CNAME at the zone apex. If your CDN requires apex routing, either use a DNS provider that supports CNAME flattening (Cloudflare, Route 53, Porkbun all do), use the full nameserver delegation model, or set an A record pointing to a CDN-provided static IP if your provider offers one.
SSL Certificate Not Provisioning
Edge certificates provision only after the DNS CNAME or proxy is fully active. If the certificate has not issued after 30 minutes, check that no CAA record on your domain is blocking the CDN's certificate authority. Run:
If CAA records exist, add an entry that permits your CDN's CA (such as letsencrypt.org for Cloudflare's Universal Cert or amazon.com for ACM).
Redirect Loops
This usually happens when the CDN's SSL mode is set to Flexible and the origin server is configured to force HTTPS via an .htaccess or server rule. The CDN connects to the origin on HTTP, the origin redirects to HTTPS, the CDN serves that redirect to the browser, which tries HTTPS at the CDN again — infinite loop. Fix: set SSL mode to Full or Full (Strict) and disable any server-side HTTP-to-HTTPS redirect that overlaps with the CDN's own redirect rules.
Dynamic Content Being Cached
If users are seeing each other's data, the CDN is caching pages it should not. Add Cache-Control: no-store to all authenticated responses. Also configure a page rule or cache rule in your CDN dashboard to bypass cache for URLs containing session cookies or for specific path patterns like /account/*, /cart/*, and /checkout/*.
Lowering DNS TTL Before Cutover and Raising It After
A frequently skipped but important step: before you make any DNS change, lower your TTL to 300 seconds (5 minutes). This means if something breaks after the cutover, rolling back by changing the record will take effect within 5 minutes rather than 1 to 24 hours. After the CDN has been running stably for a few days, raise your TTL back to 3600 seconds or higher to reduce DNS query load and improve resolution speed for visitors.
Preventing Future Issues
- Document every DNS record before making changes. Export your zone file as a backup.
- Monitor your site with uptime tooling that checks from multiple geographic regions. A CDN failure that breaks one region will not show up on a single-location monitor.
- Set up origin firewall rules so that only CDN IP ranges can reach your origin server directly. This prevents attackers from bypassing your CDN by hitting your origin IP. Your CDN provider publishes its IP ranges for this purpose.
- Test cache purge workflows before you need them in an emergency. Every CDN has an API for purging by URL or tag — know how to use it before a stale page causes a business incident.
- Keep the CDN's edge certificate and origin certificate renewal processes automated. A lapsed origin certificate causes CDN-to-origin failures that appear as 502 errors to end users.
Setting up a CDN through DNS is one of the highest-leverage performance and reliability improvements you can make to a web property. The DNS changes themselves take minutes; the planning, verification, and cache tuning take a bit longer but pay off every time a visitor in a distant city gets a sub-second response instead of a four-second wait.