dnsglobe: The DNS Propagation Checker That Turns “It Depends” Into a Live System
A Rust terminal app that watches 34 global resolvers, groups equivalent answers, decodes stale cache states, and reveals where anycast traffic really lands.
- dnsglobe treats DNS propagation as a changing state problem, not a yes-or-no lookup problem.
- Answer grouping is the key trust feature, because reordered IP sets do not count as disagreement.
- TTL-aware stale-state logic turns a vague mismatch into a debugging signal about cache lag versus upstream lag.
- The globe is useful because it visualizes convergence, not because it makes the terminal look flashy.
DNS tools often lie by simplification. They show a green check or a red X, as if every resolver on earth should agree at the same instant. dnsglobe starts from a more honest premise: DNS changes spread through a messy network of caches, resolver policies, anycast hops, and TTL boundaries.
That makes the tool interesting before you even get to the globe. The project, built by 514-labs, uses a terminal UI to watch 34 public resolvers in parallel and then explains what kind of disagreement you are actually seeing. It is less a lookup utility than a convergence debugger.
DNS propagation is not a single moment
The phrase “DNS propagation” is convenient, but it hides the real mechanism. A record change does not land everywhere at once. Resolvers keep old answers until their caches expire, some upstreams lag, and some providers return different results because the zone itself is deliberately varied by round-robin or GeoDNS.
| Situation | Naive checker | dnsglobe |
|---|---|---|
| Round-robin rotation | Looks like conflicting data | Recognizes equivalent answer groups |
| TTL expiry | Shows an old record without context | Flags stale state and why it is stale |
| Anycast routing | Treats the resolver as a black box | Tries to identify the actual POP |
| Cutover monitoring | One-off lookup | Watch mode until convergence |
Think dnschecker.org / whatsmydns.net, but in your terminal, with watch mode: start a check and it re-polls until the record has propagated everywhere.
What dnsglobe actually measures
The core unit is not the resolver alone. It is the resolver plus the answer it returned, the time it returned it, and whether that answer is still considered fresh. The app fans out to global vantage points, then classifies each response into a small number of meaningful states: records, no records, servfail, or error.
That distinction matters because timeouts do not mean the same thing as bad data. In dnsglobe, a timeout is not counted the way a stale response is counted. That lets the tool distinguish between missing evidence and actual disagreement.
enum QueryResult {
Records(Vec<String>),
NoRecords,
ServFail,
Error(String),
}
// Timeouts are tracked separately from real DNS states.
// That keeps convergence math honest.Why answer grouping matters more than a raw list of IPs
This is the smartest part of the tool. A raw IP list makes round-robin DNS look broken when it is actually behaving normally. dnsglobe groups equivalent sets, so reordered answers do not trigger a false alarm.
| Case | Naive interpretation | dnsglobe interpretation |
|---|---|---|
| [IP1, IP2] vs [IP2, IP1] | Conflict | Same group |
| Fresh answer after TTL | New state | Valid convergence candidate |
| Old answer past TTL | Just old | Stale state that needs explanation |
| Timeout | Failure | Excluded from percentage math |
That tiny correction changes the whole workflow. Instead of asking, “Why are there two different answers?” you can ask, “Are these really different, or did the resolver just return the same set in a different order?”
The stale-state logic is the real debugging feature
The tool goes beyond “old” and “new.” It separates a resolver that is merely behind from one that appears to be ignoring TTLs. That means the output is not just status, it is diagnosis.
| Verdict | What it suggests | Why it helps |
|---|---|---|
| Past TTL | A cache that should have expired | Points to a resolver or network oddity |
| Upstream | The authoritative side is still lagging | Explains why the change has not settled |
| ServFail | A valid but broken response | Separates protocol failure from stale data |
Setting TTL to some really low number a full day before making a major change is no guarantee that your zone will expire in a bunch of places. All kinds of weird ISPs try to do things with the dns results they present to their customers.
How the globe earns its keep
The globe is not a gimmick bolted onto a list view. It gives a spatial shape to a distributed problem. A flat table tells you that multiple resolvers disagree. The morphing map tells you where that disagreement is clustering and whether the system is converging or still split.
Under the hood, the visual shift from flat map to globe is doing conceptual work. It reminds you that these answers come from a world of different vantage points, not from one server with a single truth.
Anycast hunting turns a global resolver into a specific place
The most delightful trick in dnsglobe is that it does not stop at the resolver IP. It makes sidecar queries to infer which point of presence actually answered, which turns an abstract anycast address into a physical location on the map.
That is what makes the map feel earned. It is not just plotting IP addresses. It is trying to reveal the place behind the address.
Why this beats the usual alternatives
| Tool | Interface | Global coverage | Watch mode | Answer grouping | Anycast POP ID | Best for |
|---|---|---|---|---|---|---|
| DNSChecker, WhatsMyDNS | Web page | Yes | No | No | No | Quick browser checks |
| doggo | CLI | Partial | No | No | No | General DNS lookups |
| mhost / mdive | CLI and TUI | Broad | Some | Limited | No | DNS Swiss-army workflows |
| dnsglobe | Terminal TUI | 34 resolvers | Yes | Yes | Yes | Watching cutovers settle |
The competitive edge is not that the alternatives are bad. It is that they solve broader problems. dnsglobe is narrow in a good way. It is optimized for the painful moment when a record change should be done, but the world has not agreed yet.
Rust and Ratatui are the enablers, not the headline
Rust gives the project a fast single binary. Tokio lets it fan out to many resolvers without turning the UI into molasses. Ratatui makes the terminal feel alive enough to support the globe, the watch loop, and the visual state changes.
But the stack is only valuable because it serves the model. dnsglobe is good because it treats DNS as a live system with states, transitions, and convergence. The UI is just the most readable way to expose that idea.
