{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
Use one public hostname such as www.example.com. No DNS request runs until you choose Trace alias chain.
A/AAAA for web addresses, MX for mail, TXT for validation, or CAA for certificate-authority policy.
All public views compares Cloudflare, Google Public DNS, and DNS.SB.

{{ workflowFeedback }}

The default eight-hop budget is neutral for ordinary provider chains.
Optional, without a leading dot; for example cloudfront.net. Blank means no suffix expectation.
Use 1000-10000 milliseconds. The neutral default is 4500 ms.
ms
ResolverStepOwnerTarget / answerTTLNoteCopy
{{ row.resolver }}{{ row.step }}{{ row.owner }}{{ row.target }}{{ row.ttl }}{{ row.note }}

{{ values.verdict }}

{{ briefLead }}

{{ values.aligned_resolver_count }}/{{ values.successful_resolver_count }} aligned
Requested name
{{ values.requested_name }}
Primary landing
{{ values.primary_landing }}
Terminal read
{{ values.total_terminal_answers }} {{ values.terminal_type }} answer{{ values.total_terminal_answers === 1 ? '' : 's' }} across successful views
Suffix check
{{ suffixSummary }}

Recommended next checks

  1. {{ step }}
Nameserver Health Check Check a domain’s resolver-visible nameserver set and verify address coverage, SOA presence, and cross-resolver drift before a DNS cutover.
SRV / NAPTR Service Discovery Check Trace SIP/SIPS, XMPP, or LDAP discovery through NAPTR and SRV to terminal addresses with optional public resolver comparison.
Resolver Policy Difference Comparator Compare public DNS answers across open and filtered profiles to separate policy splits from cache or DNSSEC drift with repeatable evidence.
MX Record Lookup Inspect a domain's MX route and compare public DNS answers while catching Null MX conflicts, unresolved exchanges, and alias targets.

A hostname may be only the first name in a longer Domain Name System (DNS) route. A Canonical Name record, or CNAME, says that its owner is an alias and points to another name. That target can point to another alias before the lookup reaches the address, mail exchanger, verification text, or certificate-authority policy that a service actually uses.

This matters most during provider changes. The first alias can look correct while a later hop still lands on an old content delivery network, and separate recursive resolvers can keep different cached routes until their time to live (TTL) values expire. Comparing the full route helps distinguish an incomplete cutover from a client that simply has an older cached answer.

Alias owner
The name queried at the current step.
Canonical target
The next name supplied by its CNAME record.
Terminal answer
The selected non-CNAME record found after the last visible alias.
Resolver view
One recursive resolver's cached answer at the moment of the request.

A direct answer is valid too. When the requested name has no CNAME, the route has zero alias hops and the selected record type is queried at that original name. Conversely, a visible chain without its expected terminal record is incomplete evidence even when every alias points somewhere.

Resolver agreement is not the same as authoritative truth. Public resolvers may agree because they hold the same cached data, while an authoritative nameserver or the service reached through HTTP, TLS, or SMTP can reveal a different problem. Treat a recursive trace as a focused cutover and diagnosis check, then verify the service that depends on the record.

How to Use This Tool:

Trace one public hostname and choose the terminal record that represents the service you are checking.

  1. Enter the Hostname without a path or query string. A full URL is accepted, but only its hostname is used.
  2. Choose the Terminal record. Use A or AAAA for web addresses, MX for mail routing, TXT for published verification text, or CAA for certificate-issuance policy.
  3. Select one resolver or All public views. Keep the default eight-hop budget for an ordinary route, and add an Expected canonical suffix only when every successful landing should end in a known provider domain.
  4. Choose Trace alias chain, then read the outcome before using the ledger. If a request times out, retry first and increase the timeout only when network delay is the likely cause.

Interpreting Results:

The route outcome gives priority to missing evidence and disagreement. No usable resolver route means every selected view failed, while Resolver views diverge means at least one successful route or terminal answer differs from the first successful view. A failed resolver is reported separately and never counted as agreement.

Compare owner, target, and terminal rows before comparing TTL or latency. Different remaining TTLs are normal because caches count down independently. A different alias target, landing name, or terminal record set is the material difference.

  • Terminal RRset not visible means the alias route settled but the selected record type was absent.
  • Canonical suffix mismatch means at least one successful landing name did not equal or end with the expected suffix.
  • Hop budget reached or Loop detected is an unfinished route, not a successful landing.
  • An AD set label reports the resolver's authenticated-data flag; it does not replace an authoritative query or an application-level check.

Technical Details:

A CNAME lookup advances one owner at a time. Each returned target becomes the next owner, and the route stops when no further CNAME is found. The selected terminal record is then requested at that final name. A repeated target is a loop; a remaining CNAME after the allowed number of steps means the hop budget ended before the route settled.

Lookup Core

The lookup uses the same record type and limits for each selected public resolver, so the resulting views can be compared on like-for-like evidence.

Stage Evidence retained Stop condition
Follow aliases Owner, target, and the smallest TTL among matching CNAME answers No CNAME, repeated target, request failure, or hop limit
Read terminal record A, AAAA, MX, TXT, or CAA answers and their TTLs Successful answer, empty answer, or request failure
Compare resolvers Ordered alias targets, final landing name, and sorted terminal answers All selected views have been classified

TTL and request latency do not form part of the route signature. Terminal-answer order is also ignored, because a multi-record response may return the same set in a different order. The alias target order is retained because changing a hop changes the route.

Rule Core

Priority Condition Outcome
1 No resolver completed a usable route No usable resolver route
2 One or more successful signatures differ from the first successful view Resolver views diverge
3 No successful view contains the selected terminal answer Terminal RRset not visible
4 An expected suffix is present and not every successful landing matches it Canonical suffix mismatch
5 None of the earlier conditions applies Route traced or resolver views align

When a terminal answer is absent, a negative-cache hint may be read from the authority section's SOA record. The usable hint is the smaller of the SOA record TTL and its minimum field; the route summary reports the largest such hint across views. It is a retry clue, not proof that the record is absent from every authoritative server.

Hostnames are normalized to lower case without leading or trailing dots. A valid request needs at least two labels, each label may contain up to 63 characters, and the complete name may contain up to 253 characters. The hop budget ranges from 2 to 12 and the resolver timeout from 1,000 to 10,000 milliseconds.

Privacy Notes:

The hostname, selected record type, and each alias target are sent directly from the browser to the selected public DNS-over-HTTPS resolvers. Those providers can observe the requests under their own logging and privacy policies.

  • No lookup runs until Trace alias chain is chosen.
  • The representative trace is fixed local sample data and sends no DNS request.
  • Do not enter private split-DNS names or internal hostnames that should not be disclosed to a public resolver.

Worked Examples:

CDN cutover with one stale view

Suppose two resolvers follow shop.example.com through two aliases to dualstack.example-cdn.net and return the same A records, while a third lands on legacy.example-cdn.net. The result is Resolver views diverge even if every request succeeded. Compare the differing TTLs, wait through the largest relevant cache window, and confirm the route on the authoritative nameservers before changing DNS again.

References: