DNSGlobe: Watch DNS Changes from Your Terminal

DNS changes are simple until the incident channel asks why one region still reaches the old endpoint. Local dig output only proves what your resolver sees. A web checker helps, but it is awkward to script during a deployment.

DNSGlobe brings that workflow into the terminal. It is a Rust TUI that queries public DNS resolvers around the world in parallel, compares their answers, and shows the current state on a resolver table and world map.

What Is DNSGlobe?

DNSGlobe is a global DNS propagation checker for operators who want live feedback without leaving the shell. It checks 34 public resolvers, including Google, Cloudflare, Quad9, regional providers, and public resolvers in North America, Europe, Russia, the Middle East, East Asia, Australia, New Zealand, and Brazil.

The tool queries each resolver directly, uses EDNS0, and falls back to TCP for truncated answers. It also groups answers that share any record, so round-robin DNS does not become fake conflict noise when different resolvers cache different members of the same pool.

Key Features

• Watch mode: Re-polls every 30 seconds until all checked resolvers agree.
• Terminal map: Shows resolver status on a world map in wide terminals.
• Script mode: --once prints results and exits, which fits CI, runbooks, and release gates.
• Useful record types: Supports A, AAAA, CNAME, MX, NS, TXT, and SOA.
• Outlier detection: Flags resolvers that differ after all results arrive.

Installation

Install DNSGlobe with Homebrew, Cargo, or a prebuilt release:

brew install 514-labs/tap/dnsglobe
cargo install dnsglobe

For locked-down operations workstations, prefer the release binary path so every engineer runs the same version during a change window.

Usage

Start the TUI and type a domain:

dnsglobe

Query a domain immediately and keep watching:

dnsglobe example.com

Use --once when you need plain output for automation:

dnsglobe --once example.com A
dnsglobe --once example.com TXT

That makes it practical to add a lightweight DNS validation step before shifting traffic, rotating TXT validation records, or closing a migration ticket.

Operational Tips

Treat the output as resolver visibility, not magic propagation. DNS resolvers are not coordinated with each other. Old answers disappear as cache entries expire, and that timing depends on TTLs, resolver behavior, negative caching, and client paths.

Before a risky DNS change, lower TTLs early and record the expected answers. During the change, watch both the old and new records. After the change, check from your own production regions too, because public resolvers do not prove what private VPC resolvers, node-local caches, or service mesh DNS paths see.

For incident response, pair DNSGlobe with synthetic checks. If the DNS answer is correct globally but users still fail, move down the stack: CDN config, ingress health, TLS/SNI, routing, firewall policy, and application readiness.

Conclusion

DNSGlobe is a small tool with a useful operational shape. It gives SRE teams a fast way to see resolver disagreement during DNS changes, and it turns a vague "wait for propagation" step into something visible enough to put in a runbook.

Need faster root cause analysis across DNS, ingress, Kubernetes, and service dependencies? Try Akmatori and use Gcore for resilient edge infrastructure.