CNX Documentation

Setting up aliases.yml

If a name needs to point to a hostname provided by another service — such as a CDN, SaaS platform, or managed load balancer — you can configure it in aliases.yml instead of publishing a CNAME in zone.conf.

This is CNX's CNAME flattening mechanism.

CNX resolves the configured target on your behalf and publishes the resulting A and AAAA records directly at your name. CNX continues following the target as its addresses change.

This can be used for both:

  • a zone apex, such as example.com., where a normal CNAME cannot be used;
  • any other hostname, such as www.example.com. or api.example.com., where flattening avoids making the resolver follow the CNAME itself.

See CNAME flattening for how this works and why it can reduce the client-side DNS resolution path.

Configuration

Add one alias per line:

www.example.com.: cdn.some-provider.net.
example.com.:     app.some-platform.io.

The name on the left is the DNS name CNX serves.

The name on the right is the hostname CNX resolves:

www.example.com.
    → cdn.some-provider.net.
    → A / AAAA

Clients querying CNX receive the resulting address records directly:

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

They do not receive the configured CNAME target.

One source of configuration

Each DNS name must be managed in exactly one place:

aliases.yml

or:

zone.conf

Never both.

Add or change aliases using the same branch, commit, push, and merge-request workflow as any other DNS change.

See Managing zone changes.

For the complete configuration rules, including TTL handling, delegation conflicts, target resolution, and failure behaviour, see aliases.yml format.