| # | Zone | Nameservers / IP | Copy |
|---|---|---|---|
| {{ idx + 1 }} | {{ s.zone || 'root (.)' }} | {{ s.ns }} |
Domain names resolve through a chain of authoritative servers that delegate responsibility from the root to your zone. Seeing the DNS delegation path for a domain helps explain where answers come from and why records may differ across resolvers.
Delegation tracing reveals each zone and its nameservers, then shows the final addresses that a hostname returns. You provide one domain and the analyzer builds the step by step picture so you can compare what should happen with what you observe.
Results are practical when diagnosing missing glue, spotting loops, or confirming a recent change. For example, entering a hostname after moving nameservers should show the new delegation and the expected addresses so you know propagation has taken effect.
Use consistent inputs and repeat a check if you change options. Treat a valid structure as a necessary condition only, since an address that resolves can still be unreachable due to unrelated issues like firewalls or application errors.
Choose this trace when you need the delegation story rather than a single record lookup. A simple habit is to include IPv6 lookups when you expect dual stack service so the address view stays complete.
The analysis observes the Domain Name System delegation chain and the address answers for a single hostname. It inspects nameserver sets at each zone cut and collects Internet Protocol version 4 and, when enabled, Internet Protocol version 6 addresses. The snapshot reflects the moment of the query.
Computation proceeds by deriving all suffix zones of the hostname, querying nameserver records at each zone, and optionally resolving addresses for those nameservers. If the hostname is an alias, the tool can follow the canonical name chain before asking for addresses on the terminal name. This transformation clarifies where delegation hands off and where address records live.
Results consist of an ordered list of zones with their nameservers and a final line with the collected addresses. Near a transition, brief differences may appear due to caching or negative answers. Comparing runs with the same resolver setting makes changes easier to spot.
Scope and comparability depend on the chosen DNS service. The delegation story is resolver specific and timing sensitive, so caches and upstream policies can influence intermediate answers. The output is a point in time view rather than an authoritative audit.
| Symbol | Meaning | Unit/Datatype | Source |
|---|---|---|---|
host |
Input hostname without trailing dot | string | Input |
zones |
Ordered suffix zones from root to host |
string[] | Derived |
NS(z) |
Nameserver set for zone z |
string[] | Derived |
CNAME |
Alias mapping for a name when present | string | Derived |
A(name) |
IPv4 address answers for name |
IPv4[] | Derived |
AAAA(name) |
IPv6 address answers for name |
IPv6[] | Derived |
Interpretation: the zone list shows delegation from the root to the hostname, and the final address lines reveal what clients will receive using the same resolver setting.
| Parameter | Meaning | Unit/Datatype | Typical Range | Sensitivity | Notes |
|---|---|---|---|---|---|
| Resolver | DNS service used for all lookups | enumeration | Cloudflare, Google, Quad9 | High | Controls all answers returned. |
| Resolve IPv6 | Include AAAA lookups | boolean | Off or On | Medium | Off by default. |
| Show NS IPs | Resolve addresses for each nameserver | boolean | Off or On | Low | Adds context to delegation. |
| Follow CNAME | Walk alias chain before address lookup | boolean | Off or On | Medium | Up to 10 hops. |
| Field | Type | Min | Max | Step/Pattern | Error Text | Placeholder |
|---|---|---|---|---|---|---|
| Domain | string | 2 labels | 253 chars | ^[a-z0-9.-]+$ with label length 1–63, no leading or trailing hyphen, no consecutive dots |
Enter a valid domain. | example.com |
| Input | Accepted Families | Output | Encoding/Precision | Rounding |
|---|---|---|---|---|
| Hostname text | Plain ASCII domain, optional trailing dot removed | Trace table | UTF‑8 text | Not applicable |
| — | — | JSON export | Pretty printed with two‑space indent | Not applicable |
| — | — | CSV export | Comma separated values | Not applicable |
Queries are issued from the browser to the selected DNS service. No application account, upload, or persistent storage is required for tracing.
DNS delegation and address resolution for one hostname produce a readable trace of zones, nameservers, and final addresses.
Example: Input example.com, enable IPv6, and follow aliases to compare address families on the final line.
No account or server storage is used by this trace. Lookups are sent from your browser to the DNS service you select, and downloads occur locally.
Resolver providers may keep their own logs.It reflects what the chosen resolver returns at the time you query. Caches, negative responses, and policy can affect intermediate steps briefly.
Input is a hostname in plain ASCII. Output appears as a trace table and can be copied as JSON or downloaded as CSV.
No. It must contact a DNS service to fetch delegation data and addresses.
There is no sign‑in or payment step. Normal network usage applies with your chosen DNS service.
Enable alias following, run the trace, and read the inserted lines that show each hop from the alias to the terminal name before address resolution.
A borderline case is when delegation is present but addresses are missing or stale. Check resolver choice, cache timing, and authoritative zone content.
Tip Compare traces before and after a nameserver change to confirm delegation updates.
Tip Include IPv6 when verifying dual stack content delivery.
Tip Use nameserver IP display to spot mismatches between delegation and actual hosting endpoints.
Tip Rerun after a few minutes when caches may delay new answers.
Tip Read the final line closely when a CNAME target differs from the zone apex.
Tip Copy the JSON payload to attach a reproducible trace to change tickets.