dnsglobe: a terminal DNS propagation checker that queries 34 resolvers at once

The gap dnsglobe fills: resolver vantage points, not authoritative answers

When you change a zone, the question that matters is not whether your nameserver has the new record. It is which recursive resolvers have picked it up and which are still serving the old one. Web checkers answer that question but live in a browser tab, and they usually sample from infrastructure you cannot inspect. dnsglobe puts the same idea in a terminal, aimed at engineers who are already in a shell when they publish a change and want to watch it land.

The audience is narrow on purpose. If you run authoritative DNS, you already have dig against your own nameservers and your provider's dashboard. dnsglobe is for the person who just flipped a CNAME and now has to answer "is it live yet?" for the next twenty minutes. Watch mode is the feature that follows from that: the README states that pressing Enter starts the check and re-polls every 30 seconds until propagation reaches 100 percent, so you can leave it running next to your editor instead of refreshing a web page.

How the 34-resolver query loop and the propagation gauge work

Each resolver in the built-in list is queried directly. The README is explicit that this means no cache, EDNS0, and TCP fallback for truncated answers, so what appears on screen is each server's own current view rather than a value relayed through an intermediate. The list spans global anycast networks (Google, Cloudflare, Quad9), plus regional operators in North America, Europe, Russia, the Middle East, East Asia, and the southern hemisphere such as Telstra AU, SafeSurfer NZ and UOL BR.

The comparison logic is the part worth understanding before you trust a number. Answers that share any record are grouped, so round-robin DNS where each resolver cached a different subset of an IP pool counts as one consistent answer rather than twenty conflicts. The propagation gauge reports how many resolvers sit in the majority group, and outliers are flagged as differing once all results are in. That grouping choice makes the gauge lenient by design: a zone with a genuinely divergent answer can still show a high percentage if the divergent values happen to overlap the majority set.

Two smaller mechanisms shape what you see. Resolvers are asked to identify their answering site through NSID (RFC 5001), with operator-specific fallbacks for Quad9, Cloudflare, Google, OpenDNS, CleanBrowsing and Neustar UltraDNS; the discovered site appears as a YUL-style code and moves that resolver's dot to the POP actually serving your queries. The table is also built to fit 80 columns, which is why the per-row verdict collapses to a single glyph in the left margin and the TTL countdown is deliberately coarse at 45s, 4m, 2h and 1d.

Installing dnsglobe and running a first check

The README lists package-manager routes for macOS, Linux and Nix, plus prebuilt binaries on the GitHub Releases page. Pick whichever matches your machine; the Homebrew tap and the crates.io install are the two shortest paths.

brew install 514-labs/tap/dnsglobe
cargo install dnsglobe
yay -S dnsglobe
nix run github:514-labs/dnsglobe

Running it with no arguments opens the TUI empty so you can type a domain. Passing a domain starts the query immediately and enters watch mode.

dnsglobe example.com
dnsglobe example.com TXT

The second form begins on TXT records instead of A. Inside the TUI, Tab and Shift-Tab select the record type from A, AAAA, CNAME, MX, NS, TXT and SOA, and re-query. Ctrl+O toggles the world view between the flat map and the rotating globe; the README notes that terminals at or above 157 columns get the map and at or above 131 columns get the globe, with resizing across the threshold morphing one into the other.

For scripts and CI, --once skips the TUI entirely and prints results before exiting, which is the form to use when you want output you can grep.

dnsglobe --once example.com TXT

If you need to see the zone as a particular client network does, attach an EDNS Client Subnet. Subnets are CIDRs or bare IPs, and most public resolvers honour at most /24 for IPv4 or /56 for IPv6.

dnsglobe example.com --ecs 203.0.113.0/24
dnsglobe --once example.com --ecs 203.0.113.0/24,198.51.100.0/24

The second command runs every subnet and ends with a per-subnet convergence summary. In the TUI, Ctrl+N cycles the active subnet plus an off position and re-queries immediately.

EDNS Client Subnet changes the answer, and some resolvers refuse to play

The ECS support is the most interesting design decision here and also the easiest to misread. When you attach a subnet, GeoDNS zones answer for that client network rather than for the resolver's own location. That is what you want when debugging a CDN or a regional failover. The complication is stated plainly in the README: resolvers that deliberately ignore ECS, Cloudflare and Quad9 among them, are tagged NO ECS, and their answers are shown for reference but excluded from the propagation percentage.

That exclusion is correct, because an answer that describes the resolver's own location cannot tell you anything about the probed network. It also means the denominator of the gauge shrinks. If several of the 34 resolvers are tagged NO ECS, your propagation percentage is computed over a smaller set than the table suggests, and the number on screen is not comparable to a run without --ecs. Read the tags, not just the gauge.

Where dnsglobe is the wrong tool

dnsglobe samples public recursive resolvers. It does not query your authoritative nameservers, so it cannot tell you whether the record exists in the zone file or whether a secondary failed to transfer. It reports resolver answers, and the README documents no DNSSEC validation status, no delegation or glue diagnostics, and no zone-transfer tooling. If your problem is at the authoritative layer, this is the wrong program.

The built-in resolver list is a fixed set of 34 operators. It is not a random sample and not a geographic census, so a clean screen means those 34 servers agree, nothing more. The README does not document any historical storage: results exist for the session, and closing the TUI discards them. There is no API, no metrics endpoint and no database, so dnsglobe cannot back an alerting pipeline on its own. The --once mode prints and exits, which is scriptable, but the output format is not documented as a stable interface, so parsing it is a bet against future releases.

One more constraint worth noting before you plan around ECS: the README states that most public resolvers use at most /24 for IPv4 or /56 for IPv6. Subnets longer than that are not meaningful to the resolvers you are asking.

dnsglobe compared with whatsmydns.net and dnschecker.org

The README positions dnsglobe as "think dnschecker.org / whatsmydns.net, but in your terminal, with watch mode". The difference is not cosmetic. Browser checkers run their queries server-side from infrastructure the operator controls, then render a page; you get a snapshot and a refresh button. dnsglobe runs the queries from your machine against a resolver list you can edit, and keeps polling on a 30-second interval until the record reaches 100 percent.

That local execution cuts both ways. You get the plus key to add a resolver for the session by name, IP and optional location and map position, and Ctrl+X to remove the highlighted one, which the web tools do not offer. You also inherit your own network's reachability: if your egress blocks a resolver or a path is slow, that shows up as an error row rather than being smoothed over by the operator's infrastructure. A TOML config file at ~/.config/dnsglobe/config.toml extends or replaces the built-in list, with replace = true to watch propagation across only your own nameservers, and DNSGLOBE_CONFIG to point at a different path.

replace = false
ecs = ["203.0.113.0/24"]
view = "auto"

The view key accepts auto, map or globe, and the --view flag overrides it. The README does not document whether the config file supports per-resolver entries beyond what the session keys add, so treat the file as a list-level control rather than a full resolver database.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.5.0 on 2026-08-07, v0.4.0 on 2026-07-11 and v0.3.1 on 2026-07-06, so the project is moving on a roughly monthly cadence. That matters for a tool whose value depends on a hardcoded resolver list, because operators change hostnames and anycast POPs over time; a resolver list that stops being updated degrades quietly.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, but the MIT text carries no patent grant, so if your organisation cares about that, it is a question for your own counsel rather than something the repository resolves.

Upgrade cost is low in normal use. The binary has no server component and no state directory beyond the optional config file, so replacing it is a package-manager operation. The one thing to check on each upgrade is the config schema: the README documents replace, ecs and view, and a new release could add or rename keys. The Cargo.toml pins rust-version = 1.85 and edition = 2024, so building from source on an older toolchain will fail rather than degrade.

Editorial conclusion

Adopt dnsglobe if you push zone changes and want a resolver-by-resolver view without leaving the shell, or if you need to see how a GeoDNS zone answers a specific client subnet through --ecs. Skip it if you need authoritative-server checks, DNSSEC validation status, or a record of what happened last week, because the README documents none of those. Before relying on it, run dnsglobe --once example.com and confirm the count of NO ECS resolvers and error rows matches your expectations for the record type you care about.

Frequently asked questions

Official sources

1. 514-labs/dnsglobe on GitHub
2. Issues
3. License: MIT
4. README
5. Releases