CNAME Flattening Explained: How Providers Fake an Apex CNAME
It looks like a CNAME in the dashboard. It isn't one by the time it leaves the provider's servers — and that difference is exactly what makes it work.
Solving a Rule Without Breaking It
The apex restriction covered elsewhere on this site is a hard rule — a CNAME simply cannot exist at a name that also needs NS and SOA records. Flattening doesn't break that rule. It sidesteps it entirely, at a layer the rule was never written to cover: instead of publishing an actual CNAME record externally, the provider resolves the target hostname on its own infrastructure, at query time or on a refresh schedule, and hands the outside world a completely standard A or AAAA record. From the resolver's perspective, nothing unusual happened — it just got an address, the way it always does at an apex.
What Actually Happens Behind the Scenes
You Configure What Looks Like a CNAME
In the dashboard, you enter a target hostname at your apex, exactly as you would for a normal CNAME anywhere else.
The Provider Resolves It Internally
Rather than publishing that pointer externally, the provider's own infrastructure looks up the target's current A/AAAA address.
A Standard Address Record Is Served
What actually leaves the provider's nameservers and reaches the public internet is a normal, standards-compliant A or AAAA record.
Refresh Happens on the Provider's Own Schedule
The provider periodically re-resolves the target to keep the served address current — the interval and mechanism vary by provider.
Flattening vs a Traditional CNAME
| Aspect | Traditional CNAME | Flattened CNAME |
|---|---|---|
| What's actually published externally | A CNAME record, literally | A synthesized A/AAAA record |
| Works at the apex domain | No | Yes |
| Who resolves the chain | The querying resolver, hop by hop | The provider, internally, ahead of time |
| Freshness depends on | Every hop's own TTL | The provider's internal refresh interval |
Flattening vs ALIAS/ANAME
Conceptually, these are the same idea wearing different provider labels — both solve the apex restriction by resolving a target internally and serving a synthesized address record. The differences that actually matter in practice are implementation details: exact refresh timing, whether the feature is available on all plan tiers, and how each provider's dashboard exposes the configuration. None of this is standardized across the industry, which is exactly why reading your specific provider's own documentation matters more than assuming generic behavior.
Where Flattening Can Surprise You
| Situation | What to Expect |
|---|---|
| Target's address changes | Apex traffic updates on the provider's refresh schedule, not instantly and not tied to the target's own TTL |
| Target becomes temporarily unreachable during a lookup | Behavior varies by provider — some serve a stale cached address, others may briefly fail |
| Migrating away from a flattening provider | You'll need to determine the target's actual current address and configure a standard A/AAAA record directly |
Real-World Use Cases
Common Mistakes
| Mistake | Consequence |
|---|---|
| Assuming flattening updates as fast as the target's own TTL | Apex traffic may lag behind an expected change until the provider's own refresh cycle runs |
| Migrating providers without checking the resolved address first | Risk of apex downtime if the new provider isn't configured before the old flattening record is removed |
| Assuming all providers implement flattening identically | Behavior and refresh timing genuinely differ — always check your specific provider's documentation |
Best Practices
Treat flattening as a genuinely different mechanism from a real CNAME, not a cosmetic variant — its freshness model depends on your provider's internal refresh behavior, not the target's TTL. Document which provider-specific feature you're using and its known refresh interval, and before migrating away from a flattening setup, resolve the current target address manually so you can configure a direct A/AAAA record without a gap in service.
Related Tools
Check what a flattened apex is currently resolving to with A Record Lookup or AAAA Record Lookup. Trace a related subdomain's real CNAME chain with CNAME Lookup, or review the complete record picture with DNS Lookup. For the broader apex restriction this technique works around, read Apex Domain Issues.
FAQ
ToolsNovaHub tools are built and independently maintained with a focus on accurate, no-signup network and security utilities. Spotted an error? Let us know.
📋 Related Tools & Guides Comparison
| Resource | Type | Link |
|---|---|---|
| A Record Lookup | Tool | Open Tool → |
| CNAME Lookup | Tool | Open Tool → |
| Apex Domain Issues | Guide | Read Guide → |
| CDN CNAME | Guide | Read Guide → |