Trace CNAME Alias Chain

CNAME Alias Chain

Follow one hostname through visible public-recursive CNAME hops, stop on loops or over-long chains, and show where the selected terminal RRset actually lands.

Current inputs differ from the last completed trace. Re-run before trusting the on-screen alias path.

Tracing public CNAME hops and terminal {{ activeInputs.terminalType || terminal_type }} answers...

Hostname:

Enter one service hostname or URL; only the normalized host is traced.

Terminal record type:

Query this record type on the final canonical name after the CNAME walk stops.

Resolver lens:

Choose the primary public resolver view, or let auto pick the first healthy endpoint.

Compare resolvers:

Run all built-in resolvers side by side to reveal alias or terminal RRset drift.

Hop budget:

Stop after this many visible CNAME hops so long chains and loops stay bounded.

Expected canonical suffix:

Optional provider landing suffix to flag CDN or cutover drift.

Timeout:

Applied to each resolver request before the trace marks that view as a transport issue.

Auto-run:

Run once on load when the URL already contains a hostname parameter.

Field	Value	Copy
{{ row.label }}	{{ row.value }}

No visible CNAME hops were returned for the selected hostname from the primary resolver view.

Hop	Owner	CNAME target	TTL	Note	Copy
{{ row.hop }}	{{ row.owner }}	{{ row.target }}	{{ row.ttl }}	{{ row.note }}

Field	Value	Copy
{{ row.label }}	{{ row.value }}

Resolver	Outcome	Hops	Landing	Terminal read	TTL span	Comparison	Copy
{{ row.resolver }}	{{ row.outcome }}	{{ row.hops }}	{{ row.landing }}	{{ row.terminal }}	{{ row.ttl }}	{{ row.comparison }}

Export to PDF Fullscreen

Include query parameters

Embed:

Customize embed code

Include query parameters

Wrap embed in collapsible toggle

Collapse panel by default

Hide card frame (bare iframe)

Loading behavior

Width

Height

Aspect ratio (width : height)

Max height (optional)

Collapsible heading

Collapsible description (optional)

Allow fullscreen

Referrer policy

Sandbox tokens

A CNAME record makes one DNS owner name an alias for another canonical name. When a hostname points through several providers, the visible alias path can explain where traffic should land, why a cutover still reaches an old service, or why a terminal A, AAAA, MX, TXT, or CAA record is missing.

Alias tracing is useful during CDN migrations, SaaS verification, email routing checks, and provider handoffs. It is also easy to overread. Some providers flatten apex records or synthesize answers without exposing a literal CNAME, and recursive resolvers can see different cache states for a short time.

Diagram showing alias owner, CNAME hop, canonical target, terminal record set, and resolver comparison

The practical goal is to know whether the chain settles, where it settles, which terminal records are visible, and whether the final canonical name matches the expected provider suffix.

Technical Details:

DNS resolution follows CNAME records by restarting lookup at the canonical target. A visible chain is therefore a sequence of owner name to target name hops until no direct CNAME remains or the hop budget is exhausted. The final name is then queried for the selected terminal record type.

The tracer normalizes one hostname or URL, strips paths, lowercases the owner name, and queries public DNS-over-HTTPS resolvers. Auto mode prefers the first healthy built-in resolver. Compare mode runs Cloudflare, Google Public DNS, and DNS.SB and labels outcome drift, alias drift, terminal drift, or alignment.

CNAME trace outcomes
Outcome	Meaning	Next check
Route Complete	One or more CNAME hops ended with terminal answers.	Check final name, TTL span, and suffix match.
Direct Answer	No visible CNAME, but terminal records answered directly.	Consider apex flattening or direct records.
Terminal Missing	CNAME hops ended without the selected terminal RRset.	Verify the terminal owner publishes that type.
Hop Budget Exceeded	Another CNAME remained after the configured limit.	Raise the budget only after checking intent.
Loop Detected	A target repeated inside the alias path.	Fix DNS data before expecting stable resolution.

TTL values are collected from visible CNAME hops and terminal answers. Negative-cache hints may be derived from SOA records when no terminal answer appears. Those hints help decide when to retry after a DNS change.

The expected suffix check is a string check against the final canonical name. It is useful for migrations to suffixes such as CDN or SaaS provider domains, but it does not validate TLS, HTTP routing, or service health.

Everyday Use & Decision Guide:

Start with Auto resolver, terminal type A, a six-hop budget, and no expected suffix. Add the expected suffix once you know where the service should land, then enable resolver comparison if the result affects a production cutover.

Use Terminal RRset Read to confirm the final owner actually returns the selected record type.
Use CNAME Hop Ledger when you need exact owner, target, TTL, and note for each hop.
Use Resolver Comparison when one cache view is not enough.
Stop on loop or depth warnings. Those outcomes mean the chain did not settle cleanly in the configured run.

If a hostname answers directly and you expected aliasing, check whether the DNS provider is flattening an apex record or returning synthesized records.

Step-by-Step Guide:

Enter one hostname or URL in Hostname.
Select the Terminal record type that matters for the service.
Choose Resolver lens, enable Compare resolvers if needed, and set Hop budget.
Add Expected canonical suffix for migrations or provider checks.
Press Trace Chain, then read CNAME Route Read, CNAME Hop Ledger, Terminal RRset Read, and Resolver Comparison.

If validation fails, enter a single hostname or URL. Extra lines are ignored after the first normalized hostname.

Interpreting Results:

The final canonical name and terminal summary carry the most operational weight. A suffix mismatch during migration means the alias landed somewhere other than the expected provider suffix. Resolver drift means at least one public resolver saw a different path or terminal answer.

A missing terminal RRset after a valid CNAME path can still be a DNS configuration problem. Check the selected record type before assuming the alias itself is wrong.

Worked Examples:

A hostname such as www.example.com may trace through one CNAME to a CDN target and then return A records. The output should show Route Complete, one hop in CNAME Hop Ledger, terminal A answers, and a TTL span.

If a migration expects cloudfront.net but Expected canonical suffix reports a mismatch, the chain is still landing on another provider or an intermediate target. That is a cutover blocker until DNS is corrected.

If the hop budget is set to 2 and the chain has a third visible CNAME, Hop Budget Exceeded means terminal lookup was skipped. Raise the budget only after confirming the extra indirection is intentional.

FAQ:

Can a CNAME chain be hidden?

Yes. Provider flattening or ALIAS-style behavior can return terminal records directly without exposing a literal CNAME to recursive resolvers.

Why compare public resolvers?

Different resolvers may have different cache state, policy behavior, or transport errors. Compare mode makes those differences visible.

Does suffix match prove the site works?

No. It only checks the final canonical DNS name. HTTP routing, TLS certificates, and application health require separate tests.

Glossary:

CNAME: A DNS record that identifies the canonical name for an alias owner.
Terminal RRset: The final set of records queried after the CNAME walk stops.
Resolver drift: A difference between public resolver views for the same hostname and record type.