Every CDN deployment ends at your DNS console, where three decisions decide how flexible the whole estate stays: how you CNAME, what you do about the apex, and what TTLs you run on change days versus quiet ones. This guide walks all three, plus the validation records that keep certificates automatic.
The clean case: subdomain CNAME
For any hostname that is not your zone apex — www, cdn, static, img — the configuration is one CNAME record pointing at the provider's edge hostname, and everything good about CDN operations flows from keeping it that clean. The CNAME is your steering wheel: switching providers, splitting traffic, or failing over is a record change, not an application change. Resist the temptation to CNAME to intermediate names you create yourself unless you are deliberately building a steering layer; every extra link adds a lookup and a failure point. And prefer serving your site on a CNAME-able hostname (www) with the apex redirecting to it — the single decision that sidesteps the entire next section for most estates.
The apex problem and its workarounds
The DNS standard forbids CNAME records at the zone apex (example.com), because the apex must carry SOA and NS records that CNAME would displace — yet users type apex domains and marketing prints them. The ecosystem's answers, in rough order of preference: serve the apex from a DNS provider offering CNAME-flattening or ALIAS/ANAME synthesis, which resolves the CDN's name server-side and returns A/AAAA records (most modern managed DNS supports this); use the CDN provider's own DNS, where apex support is native because they control both sides; or, failing both, a static-IP anycast option where the provider offers stable addresses for apex use. What to avoid: hardcoding whatever A records the edge hostname resolves to today — those addresses are the provider's to change, and this pattern fails months later at maximum surprise. Which providers handle apex flattening natively is one of the axes in our anycast DNS comparison.
TTLs: change-day vs steady-state
TTL strategy is a two-mode discipline. On change days — cutover, provider switch, failover test — you want short TTLs (60–300 seconds) so mistakes revert fast, and you want them lowered a full day in advance so old long-TTL answers age out before the change. In steady state, raise delivery-hostname TTLs to 30–60 minutes: it cuts resolver load, shields you from brief DNS-provider blips, and costs you nothing while records are stable. The exception is any record a steering or failover layer actively manages — those live permanently at 30–120 seconds, which is the price of the agility, and one reason steered estates care about resolver behavior more than most (a theme the steering-layer comparison develops). Write the two modes into your runbook; the classic incident is a cutover attempted against yesterday's 24-hour TTL.
Validation records and certificate automation
Modern CDN TLS is automatic exactly as long as the validation plumbing exists, so build it once, properly. For each delivery hostname, the provider will validate control either by observing the live CNAME or via a dedicated _acme-challenge (or provider-specific) validation record — create the dedicated records even when live-CNAME validation would work, because they keep renewal independent of traffic routing, which matters the day you point traffic elsewhere but still want the certificate renewing. Add CAA records naming the certificate authorities your providers use (their docs list them), so future issuance stays both automatic and policy-controlled. Five minutes here removes the entire category of expired-certificate incidents from your future.
DNS as your delivery control plane
Configured this way, DNS quietly becomes the control plane of your delivery estate: the CNAME steers, the TTLs set your reaction time, the validation records keep TLS hands-off, and the apex is served by synthesis rather than hacks. That is also why the DNS provider choice itself deserves the same diligence as the CDN — resolution is the dependency in front of every other dependency, and running a second provider in primary/secondary is the cheapest availability upgrade available, per the pattern in the anycast DNS field. Get these records right once, and every future migration in this library becomes a small change to a system built for change.