CUSTOM DOMAIN
The ticket reads: "caching isn't working on my site." You check the config. It's fine. You check the customer's DNS. The apex points at your edge. The www record still points at their old origin. Some visitors go through your cache, your WAF, your routing. The rest walk straight past it to the origin server, and no rule you write will ever touch them.
Nobody did anything wrong on purpose. The customer followed a help article, updated the record they saw, and stopped. The record they missed was invisible to them. But now your product is only doing half its job, and the only signal you get is a confused support ticket days later.
The classic forgot-the-www mistake
A site with the apex on your edge and www on the origin is not half-protected. It is unprotected for everyone who typed the wrong prefix, and the page still loads, so nobody notices until the wrong path causes a problem.
Why the edge case is the common case
When a platform sits in front of a customer's site, whether for caching, filtering, edge routing, or a WAF, the whole arrangement hinges on one thing: the domain has to point at your infrastructure so traffic flows through you before it reaches the origin. That is the entire deal. If a request finds a path around you, your product did not run.
The trouble is that a single site has several traffic paths, and a person setting up DNS by hand tends to think of one. The failure modes stack up fast, and each one leaves a working site, which is exactly what makes them dangerous.
| Failure mode | What the person did | What traffic does |
|---|---|---|
| Forgot the www | Updated the apex, stopped there | A large share of traffic bypasses your edge entirely |
| Forgot the apex | Updated www, left the bare domain | The bare domain misses you |
| Wrong destination | Copied an IP from a stale doc or the wrong line of an email | Points at the wrong place and never reaches you |
| Skipped IPv6 | Handled IPv4, never touched AAAA | IPv6 requests route around you |
The page loads, the customer moves on, and the gap sits there until traffic on the wrong path causes a problem you have to chase backward from the symptom.
Change every path in one approval
The fix is to stop treating the records as separate errands. A domain has an apex, a www, and an IPv6 path, and for your edge to actually be in front of the site, all of them have to point at you together. Custom Domain writes them as one atomic change.
These are the records a site needs to route fully through your edge, applied together rather than one at a time:
| Type | Name | Value |
|---|---|---|
| A | @ | edge.yourplatform.com (the apex, on your edge) |
| A | www | edge.yourplatform.com (the www path, same target) |
| AAAA | @ | 2606:4700:0:0:0:0:0:a1 (the IPv6 path) |
| AAAA | www | 2606:4700:0:0:0:0:0:a1 (IPv6 for www) |
Here is the shape of it. Your customer clicks connect inside your product. We detect their DNS provider and prepare the exact set of records their site needs. They approve one screen at their own provider, and every path changes in the same step. No record is left behind, because there is no step where a human decides which record to skip.
Two things follow from your infrastructure supplying the target rather than the user typing it. The customer cannot fat-finger the wrong destination, because they never type a destination. And you cannot end up with an apex on your edge and a www on their old origin, because the records are not offered as independent choices. They are one setup, applied whole or not at all.
Be honest about what you are doing to their traffic
There is a second reason to get this right, and it is not technical. Routing a customer's entire domain through a third party is a high-trust action. You are asking to sit between their visitors and their server. That deserves a clear account, not a buried checkbox.
So the consent screen says plainly what is being routed and where it is going. The customer sees that their traffic will flow through your infrastructure before reaching their origin, and they approve that with full sight of it. This is not a hurdle to smooth over. Stating it out loud is what earns the permission. A customer who understands that they are pointing their domain at your edge, and chooses to, is far less likely to file the angry ticket later asking why their traffic goes through you at all.
A site with the apex on your edge and www on the origin is not half-protected. It is unprotected for everyone who typed the wrong prefix.
What the engineer on your side gets
From your side of the integration, the payoff is narrow and real. You integrate the widget and the API once. After that, every customer who connects a domain arrives fully behind your edge, across every provider, with no per-provider instructions to write and no half-configured setups quietly escaping into the wild. The support queue stops filling with "caching isn't working" tickets that turn out to be a forgotten www record.
The point
When the DNS step is no longer a hand-typed guess, the class of bug where traffic silently bypasses your product disappears. Your edge is either in the path for a customer or it is not, and you can tell which from the moment they finish setup.
For a platform whose entire value depends on being reliably in the request path, that certainty is the point. You can see how a one-click connection works and watch the domain go behind your edge cleanly, completely, and in one step, where it stays.
Custom domains, on autopilot
Let your customers put their domain behind your edge in one click. We detect their DNS provider, write the apex, www, and IPv6 records together, verify ownership, and issue HTTPS, while they just approve one screen.
Get started