CNAME flattening

A CNAME makes one DNS name an alias of another:

www.example.com.    CNAME    service.example.net.

When a resolver asks for www.example.com., it learns that the real target is service.example.net. and must then obtain the A or AAAA records for that target.

This works well for ordinary hostnames, but a normal CNAME cannot be placed at the zone apex, such as example.com..

Why a CNAME cannot exist at the zone apex

DNS requires every authoritative zone apex to contain records such as:

example.com.    SOA    ...
example.com.    NS     ...

A CNAME, however, represents an alias and cannot coexist at the same name with other DNS data.

RFC 1034 §3.6.2 defines this rule:

If a CNAME RR is present at a node, no other data should be present.

RFC 2181 §10.1 clarifies the requirement further: a DNS name containing a CNAME may not contain other resource records, apart from DNSSEC-related records.

Because the apex must contain its SOA and NS records, this is therefore invalid:

example.com.    SOA      ...
example.com.    NS       ...
example.com.    CNAME    service.example.net.

This is a DNS protocol constraint, not a limitation specific to CNX or any particular DNS provider.

The problem becomes common with CDNs, SaaS platforms, cloud load balancers, and other managed services that give customers a hostname such as:

customer.vendor.example.

rather than fixed IP addresses.

What CNAME flattening does

CNAME flattening moves the alias resolution into the authoritative DNS service.

Instead of publishing:

example.com.    CNAME    customer.vendor.example.

CNX resolves the configured target on behalf of the zone and publishes its resulting addresses directly:

example.com.    A       192.0.2.10
example.com.    AAAA    2001:db8::10

CNX continues resolving the configured target and updates the published addresses as the target changes.

The zone therefore remains valid DNS: the apex keeps its required SOA and NS records while clients receive ordinary A and AAAA answers.

Flattening is not limited to the zone apex

The apex is the most common reason to use flattening, but CNX can apply the same mechanism to any configured alias.

For example, instead of serving:

api.example.com.    CNAME    customer.vendor.example.

CNX can resolve the target and serve:

api.example.com.    A       192.0.2.10
api.example.com.    AAAA    2001:db8::10

This changes the DNS path seen by the resolver.

With a normal CNAME:

api.example.com.
    ↓
CNAME customer.vendor.example.
    ↓
resolve customer.vendor.example.
    ↓
A / AAAA

With CNX flattening:

api.example.com.
    ↓
A / AAAA

The client or recursive resolver no longer has to follow the CNAME target itself.

Why this can improve lookup performance

A normal CNAME introduces another DNS dependency.

If the target is not already cached, the resolver must resolve that target before it obtains the address needed by the application. RFC 1034 describes this behavior explicitly: when a CNAME is encountered while answering another record type, resolution continues using the canonical name.

Flattening performs that work before the client asks.

The authoritative response can therefore contain the final A or AAAA records immediately, removing the additional CNAME resolution step from the client's DNS path.

As with most DNS optimizations, the effect is greatest on a cold cache. A recursive resolver may already have the CNAME target and its addresses cached, in which case the difference is smaller.

Flattening nevertheless removes that external alias dependency from the client-side lookup path entirely.

It can therefore be useful both:

• at the zone apex, where a normal CNAME cannot be used at all; and
• on ordinary hostnames, where flattening can reduce the number of DNS resolution steps seen by clients.

See Setting up aliases for how CNAME flattening is configured at CNX.