CDN with Anycast DNS: Three Prefixes and the BGP Problem Nobody Mentions

Most CDNs resell DNS or bolt it on. CDNShark runs authoritative DNS on its own anycast prefix, separate from the prefixes that carry traffic. This post covers why they are separate, how a lookup actually resolves, and the BGP failure mode that makes anycast much harder than "announce it from everywhere."

Three prefixes, three jobs

208.78.78.78   authoritative DNS      (Technitium + BIRD2)
208.78.78.79   data plane, transit A  (traffic routers)
208.78.79.79   data plane, transit B  (traffic routers)

Splitting the control answer from the data path means a routing problem on the data plane cannot stop your domain resolving — the failure stays visible and diagnosable instead of turning into NXDOMAIN. And the two data-plane prefixes are announced through different transit providers on purpose, so a bad path through one provider does not take the service down; clients that pick the healthy prefix keep working.

How a lookup resolves

Note step 4: TLS terminates at the edge, not at the anycast node that accepted the connection. Larger networks terminate at the first PoP. This costs a round trip and is a real architectural difference, not a detail.

The BGP problem that anycast documentation skips

The naive model of anycast is that announcing a prefix from many sites means clients reach the nearest one. What actually happens is that every remote router runs its own best-path selection, and AS path length dominates.

This has a consequence that is specific to anycast and genuinely counterintuitive. Buying transit from several providers does not mean traffic arrives over all of them. If one of your providers is reached through a chain of resellers, its AS path is longer at essentially every vantage point on the internet — so it loses best-path selection almost everywhere. With a normal unicast service that is a peering inefficiency you might never notice. With anycast, the winning path decides which physical site receives the request. A large spread in AS path length silently funnels global traffic into one PoP, no matter how good your geographic distribution looks on a map.

what you think you bought        what BGP actually does
-------------------------        ----------------------
 announce from 5 sites            AS path via reseller chain:
 traffic splits by geography      9821 -> 6939 -> 3356 -> you   (len 4)

                                  AS path via direct transit:
                                  9821 -> 3356 -> you           (len 3)

                                  shorter path wins EVERYWHERE
                                  -> one site absorbs the traffic

You cannot see this from inside your own network; your routers show what you announced, not what the world selected. It has to be read from public route collectors. CDNShark's BGP upstream checker pulls the live table from RIPE's RIS collectors and shows the real per-prefix split, and there is a paired anycast consistency report that compares announcement state per data centre to catch a site that has silently stopped attracting traffic — the black-hole case, where a PoP is up, healthy, and receiving nothing.

Health guarding without withdrawing the session

The obvious way to take a sick anycast site out of rotation is to withdraw the BGP announcement. That is usually the wrong move: withdrawing and re-announcing a prefix propagates globally, is slow to converge, and risks damping. CDNShark's anycast health guard withdraws the static origin protocol for the affected service and leaves the BGP session up, using node-local probes to decide. One corollary worth stating because it caused real trouble: a guard cannot protect a site that was never deployed, so a node must only start announcing after its service is actually live.

What you get with the DNS itself

• Authoritative anycast DNS included in every plan, not a separate product or a separate bill
• Proxied and unproxied records per hostname — proxy an A, AAAA, or CNAME to route it through the CDN, or leave it resolving straight to your host
• Record types — A, AAAA, ANAME, CNAME, DNAME, MX, NS, PTR, SRV, TXT. The nameservers themselves also support CAA, which is not yet exposed in the record editor
• Automatic provisioning — ordering a CDN domain creates the zone, the record pointing at the traffic-router anycast address, and the certificate
• ACME DNS-01 support, including CNAME-delegated validation via a dedicated validation domain, so a customer keeping DNS elsewhere can still get certificates issued
• API access to zones and records

Limitations, stated plainly

• Five authoritative nodes — Fremont, New Jersey, Kansas, London, Sydney. Well spread for the US and Europe, thin for Asia, South America, and Africa. Large DNS providers run hundreds of sites.
• No self-serve DNSSEC signing. Zone DNSSEC status is tracked, but signing your zone is not currently a customer-facing feature. If you need signed zones today, this is a blocker.
• Anycast quality is transit quality. Everything above is an argument for measuring it honestly, not a claim to have solved it. Some networks will reach a suboptimal site.
• The data plane's TLS termination happens at the edge, which costs a round trip versus networks that terminate at the anycast entry point.
• 11 edge PoPs behind the DNS layer. Good routing cannot compensate for a missing PoP in your region.

Who this is for

If you want DNS and CDN from the same account, with the routing layer documented rather than implied, and you are mostly serving North America and Europe, this is a reasonable place to run your zones. If you need DNSSEC, or your traffic is concentrated in regions with no nearby node, use a dedicated DNS provider — pointing a CNAME at CDNShark from someone else's DNS is fully supported and the CNAME-delegated ACME path exists precisely for that.