Alias chain
The CNAME / DNAME / ALIAS chain checker follows the alias chain of a name and verifies that it resolves cleanly: no loops, not too many hops, sane TTLs, a resolvable final target, no forbidden record coexistence, and a properly signed CNAME RRset when the zone uses DNSSEC.
This is a service-level checker: it runs on a CNAME (or special CNAME) service and is configured from that service’s own Checks tab. Starting from the queried name it locates the zone apex, walks each CNAME/DNAME hop, and finally resolves the chain’s target to A/AAAA records.
What it checks
Each rule emits a finding code. Some severities are softened by the options below.
| Rule | What it verifies / flags | Severity |
|---|---|---|
apex_lookup |
The zone apex (SOA) for the queried name can be located. | Critical |
chain_loop |
A CNAME/DNAME cycle in the resolution chain. | Critical |
chain_length |
The chain exceeds Maximum chain length hops. | Critical |
chain_query_error |
A DNS query fails while walking the chain (network error, timeout). | Warning |
chain_rcode |
A non-NOERROR response code mid-chain or on the final A/AAAA lookup. | Critical (mid-chain) / Warning (final) |
hop_ttl |
A CNAME/DNAME hop has a TTL below Minimum target TTL. | Warning |
cname_at_apex |
A CNAME exists at the zone apex, conflicting with SOA/NS (RFC 1912 §2.4). | Critical / Warning |
apex_flattening |
A/AAAA coexist with SOA/NS at the apex without a CNAME (provider-side ALIAS/ANAME flattening). | Info |
cname_coexistence |
Other RRsets (beyond A/AAAA) coexist at a CNAME owner, violating RFC 1034 §3.6.2 / RFC 2181 §10.1. | Critical / Warning at apex |
cname_dnssec |
The zone is DNSSEC-signed but the CNAME RRset lacks an RRSIG. | Critical |
target_resolvable |
The final target of the chain has no A or AAAA record. | Critical |
multiple_records |
An owner in the chain carries more than one CNAME/DNAME record (malformed). | Critical |
Why a CNAME at the apex is a problem
A CNAME owner may carry no other record type, but the zone apex must always hold SOA and NS records. The two requirements are mutually exclusive, so a CNAME at the apex is invalid (RFC 1912 §2.4). Some providers work around this with server-side ALIAS/ANAME “flattening” that publishes plain A/AAAA at the apex; the apex_flattening rule recognises that pattern as intentional when Recognize ALIAS/ANAME flattening is enabled.
Options
| Option | Meaning | Default |
|---|---|---|
| Maximum chain length | Above this number of hops the chain is reported as critical. | 8 |
| Minimum target TTL | Hops with a TTL below this threshold (seconds) are flagged as a warning. | 60 |
| Allow CNAME at apex | When enabled, a CNAME at a zone apex and its coexistence violations are downgraded to warnings. RFC 1912 forbids this, so leaving it off is strongly recommended. | false |
| Recognize ALIAS/ANAME flattening | When enabled, providers serving A/AAAA at the apex (ALIAS/ANAME pseudo-records) are recognised as intentional and excused from coexistence violations. | true |
In happyDomain
Add the CNAME service to the subdomain, then enable this checker from that service’s Checks tab. See /en/pages/checks/ for configuring and scheduling checks. The parent domain and subdomain are filled in automatically.
Related checkers: /en/reference/checkers/dangling/ watches for alias targets that have become unregistered or NXDOMAIN, and /en/reference/checkers/ptr/ covers the reverse-DNS side.