---
title: "Beyond CNAME Flattening"
date: "2026-09-03T04:50:00"
url: "https://www.godaddy.com/resources/news/beyond-cname-flattening"
---
# Beyond CNAME Flattening

If you've been told you need to leave GoDaddy to point your apex domain at a CDN, that advice is out of date. The DNS standard caught up. GoDaddy's Managed DNS supports SVCB and HTTPS records in full-service mode today, served across our global anycast network and they do everything CNAME flattening does, with fewer trade-offs.

This post is a tour of how apex aliasing actually works in 2026, why the older ALIAS/ANAME workaround was always a compromise, and how we run the modern alternative at scale.

## The problem CNAME flattening was trying to solve

The DNS specification has always forbidden CNAME records at the zone apex. The reason is structural: the apex has to host SOA and NS records, and a CNAME says "this name is just an alias - don't attach anything else here." The two are incompatible.

Modern infrastructure doesn't hand you a fixed IP address. CDNs, load balancers, and SaaS platforms give you a hostname. If you want example.com to resolve to your CDN, you're stuck, unless your DNS provider offers CNAME flattening (sometimes branded ALIAS or ANAME), which resolves the chain server-side and serves a synthesized A record. It works, but it was never part of the DNS standard. Every provider implemented it differently. TTL handling varies. And as we'll see, DNSSEC compatibility is a serious problem.

## Enter SVCB and HTTPS records

[RFC 9460](https://datatracker.ietf.org/doc/rfc9460/) defines two new record types. The RFC explicitly states among its design goals (§1.1) to "enable CNAME-like functionality at a zone apex". This is the IETF's sanctioned solution to the very problem flattening was patching around.

- **SVCB (Service Binding)** - a general-purpose record describing how to reach a service: supported protocols, ports, IP hints.
- **HTTPS** - a specialized SVCB record for web traffic.

Both operate in one of two modes:

- **AliasMode (priority 0)** - functions like a CNAME, delegating the apex to another hostname. Unlike CNAME flattening, this is fully standards-compliant and doesn't conflict with other records at the apex.
- **ServiceMode (priority > 0)** - directly advertises connection parameters: ALPN values like h3 and h2, port numbers, IP address hints. Clients can connect optimally on the first request.

This is the model the major CDNs are pushing - Akamai, Cloudflare, and CloudFront all publish HTTPS records for their hosted properties. The standard exists, browsers honor it, and CDNs are adopting it.

## What you get that CNAME flattening can't offer

Rather than leveraging behind the scenes magic to synthesize Apex A records stored as an Apex CNAME, HTTPS records not only create a fully transparent processing path, they also come with the following benefits for both client and server:

- Standards compliance - SVCB and HTTPS are part of the DNS specification itself. Your apex aliasing no longer depends on how your DNS provider chooses to implement a workaround.
- HTTP/3 signaling at the DNS layer - An HTTPS record with alpn=h3,h2 tells supporting clients your origin speaks HTTP/3. Previously this required an extra round trip via the Alt-Svc response header. With HTTPS records, capable clients can establish HTTP/3 from the first request. **Faster connection setup.** ServiceMode records can include ipv4hint and ipv6hint, letting clients skip a separate A/AAAA lookup. Fewer DNS round trips before the TLS handshake begins.
- Automatic HTTPS upgrading - Chrome and Safari automatically upgrade http:// requests to https:// when an HTTPS record is present for the domain. Edge follows via Chromium. It's DNS-based HSTS, without waiting for a server response.
- Encrypted Client Hello (ECH) - HTTPS records are the delivery mechanism for ECH public keys, which encrypt the SNI field (the hostname the client is connecting to) in the TLS handshake.

## The DNSSEC problem CNAME flattening couldn't solve

This is where the older workaround really shows its cracks.

CNAME flattening creates a tension with this model. The synthesized A/AAAA records the provider returns are derived from resolving the target hostname, and historically they were generated at query time with no signature attached. This means a strict DNSSEC validator sees an unsigned answer and fails the lookup. Providers have since engineered around this in two ways:

- by pre-fetching the target's addresses, adding them to the zone, and signing them through the normal zone-signing pipeline.
- by signing dynamically at the edge at serve time.

Both approaches work in practice (Cloudflare runs at very large scale on online signing), but each carries trade-offs around freshness, key custody, and operational complexity.

HTTPS records in AliasMode sidestep the question entirely. They are real, static DNS records that live in your zone like any other. The alias target is the literal value of the record, not a resolved address - so there's nothing dynamic to reconcile with DNSSEC. The record is signed at zone-signing time alongside everything else and validated by any DNSSEC-aware resolver.

## How GoDaddy signs zones

GoDaddy's Managed DNS uses pre-signed zones with offline-held keys. Records (including SVCB and HTTPS) are signed at zone-signing time, well before they reach the serving infrastructure. The keys never live on the nameservers themselves. It's a conservative model with a small trust surface and simple key custody, and it pairs naturally with HTTPS records because they're static, signable values that need no special handling.

The apex is the busiest name in your zone. Every uncached visit to your bare domain begins with an apex lookup. When the apex resolves to a CDN via an HTTPS record, the speed of that lookup directly affects time-to-first-byte for every cold visitor.

GoDaddy's Managed DNS is served from a global anycast network. Anycast routes each resolver to its nearest serving location automatically, which gives apex queries the lowest possible latency wherever the resolver is on the planet, and absorbs traffic spikes and DDoS pressure across the fleet rather than concentrating them on a single site.

For HTTPS records specifically, this matters twice: once for the apex lookup, and again if the client uses the IP hints in a ServiceMode record to skip the follow-up A/AAAA queries.

## When forwarding is the right answer

A lot of people reach for CNAME flattening when what they actually want is example.com to land users on [www.example.com](http://www.example.com/). That's not a DNS aliasing problem, it's a redirect problem, and DNS is the wrong layer to solve it at.

GoDaddy's web forwarding handles this over both HTTP and HTTPS. Set up a forward and requests to your bare domain are redirected to your www subdomain, or any other target, with proper HTTPS termination at the edge. Your DNS records stay simple, the redirect happens at HTTP rather than DNS, and you avoid the apex-aliasing question entirely.

The rule of thumb: if you actually need clients to connect to a hostname-addressed service at the apex (a CDN, a load balancer, a SaaS frontend), use an HTTPS record. If you just need clients to end up at a different URL, use forwarding.

## Setting it up

The following two scenarios provide examples of both a simple HTTPS record configuration and a more advanced HTTPS record taking advantage of the extra parameters to reduce further DNS lookups and greatly improve the connection speed from client to server.

### Scenario 1: Apex pointing to a CDN (AliasMode)

The direct replacement for CNAME flattening is one record, standards-compliant, DNSSEC-safe:

example.com. 300 IN HTTPS 0 cdn.provider.example.The following table describes each field:

FieldDescription
  
    example.com.Owner name (zone apex). The trailing dot makes it fully qualified — exactly where a CNAME would be illegal, but an HTTPS record is allowed.
    300TTL in seconds
    INClass (Internet)
    HTTPSRecord type (numerically type 65)
    0SvcPriority — zero means AliasMode; non-zero values mean ServiceMode
    cdn.provider.example.TargetName — the hostname your apex aliases to

That's it. Your apex now points at your CDN's hostname. No flattening hack, no DNSSEC conflict, no proprietary provider behavior.

### Scenario 2: Full ServiceMode with HTTP/3 and IP hints

ServiceMode goes further by advertising connection parameters so clients connect optimally from the first request:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="203.0.113.1"The following table describes the fields specific to ServiceMode:

Field | Description
--- | ---
1 | SvcPriority (non-zero means ServiceMode; clients prefer the lowest non-zero priority available)
. | TargetName of . means "the owner name itself" — resolve example.com for the IP
alpn="h3,h2" | SvcParam signaling HTTP/3 and HTTP/2 support
ipv4hint="203.0.113.1" | SvcParam giving an optional IP hint so clients can skip the separate A lookup

## A note on deployment

HTTPS records are an optimization layer, not a magic switch. Browser support is strong in Safari and Chromium-based browsers, with Firefox catching up. Not every recursive resolver passes HTTPS records through to clients (particularly some older ISP resolvers and enterprise environments).Best practice is to publish HTTPS records alongside conventional A/AAAA records and maintain standard HTTP-to-HTTPS redirects at the origin. Clients that understand HTTPS records use them; everyone else falls back gracefully. Nothing breaks.

## Where we're taking this next

We're adopting SVCB beyond the web. The Agent Name Service (ANS), an open standard identity layer for AI agents, uses SVCB for service discovery, replacing manual endpoint configuration with capabilities published in DNS itself. Stay tuned for more on ANS and SVCB in a forthcoming post.

## The bottom line

CNAME flattening solved a real problem, but it was always a patch over a gap in the standard. SVCB and HTTPS records close that gap properly, unlocking real performance and privacy improvements (HTTP/3 from the first hop, ECH, faster connection setup) that flattening could never deliver.GoDaddy supports SVCB and HTTPS records today, served from our anycast network with full DNSSEC compatibility. If a guide is still telling people they need to leave GoDaddy to point their apex at a CDN, that guide is working from a problem statement that's three years out of date.The web is moving to HTTP/3, encrypted handshakes, and faster connection setup. DNS is moving with it. We are too.