dog vs dig: The Modern DNS Lookup Comparison

CodexFuse Team · 2026-11-04T03:18:41.422Z · 11 min read min read

If you live in a terminal and look up DNS records all day, you have probably heard someone say "just use dog instead of dig" — and this dog vs dig comparison answers whether the switch is worth it. dog is a command-line DNS client written in Rust that does what dig does, but with colorful, readable output, normal command-line syntax, built-in DNS-over-TLS and DNS-over-HTTPS, and a JSON mode made for scripts. It is not a full replacement for dig, though: dig still owns the deep protocol work, like tracing the delegation chain with +trace.

If DNS itself still feels fuzzy, start with our DNS beginner guide — it explains resolvers, records, and the lookup chain this comparison builds on. And if you ever need a one-off answer without installing anything, our browser-based DNS lookup tool runs the same record queries from a web page.

What Is dog?

dog is a command-line DNS client — "like dig, but a bit different, so, dog" — created by the developer known as ogham, written in Rust, and released under the EUPL-1.2 licence. Its own tagline is "Dogs can look up!" The pitch is simple: this dog DNS client fixes the two things that annoy people about dig — the BSD-style argument order and the wall of plain-text output. Arguments are order-independent (dog recognises a record type by name, a nameserver by the leading @, and treats anything else as the domain), output is colorized by default, and encrypted transports are built in rather than bolted on.

How Do dog and dig Compare Side by Side?

Here is the honest one-screen dog command vs dig comparison. dog wins on ergonomics and modern protocols; dig wins on protocol depth and ubiquity. Neither tool makes the other obsolete.

What Does the dog Command Look Like in Practice?

It looks like plain English with the pieces in any order: dog's argument parser is order-independent, so you type the domain, the record type, and the resolver in whatever order feels natural. The official README documents these examples, and they all do exactly what they look like:

dog example.net                          Query a domain using default settings
dog example.net MX                       ...looking up MX records instead
dog example.net MX @1.1.1.1              ...using a specific nameserver instead
dog example.net MX @1.1.1.1 -T           ...using TCP rather than UDP
dog -q example.net -t MX -n 1.1.1.1 -T   As above, but using explicit arguments

The dig equivalents are shorter to write once you know them, but harder to read cold: dig example.net MX @1.1.1.1 versus the same thing. Where dog really diverges is the flag set. -q, -t, and -n give you explicit --query, --type, and --nameserver forms; the transport flags are -U/--udp (the default), -T/--tcp, -S/--tls, and -H/--https; and the output flags are -1/--short, -J/--json, --color, --seconds, and --time.

Why Is dog's Output Easier to Read?

dog's default output is a single color-coded line per record, showing the record type (for example A), the domain name, the time until the record refreshes (its TTL), and the record's main contents — an IP address for A records, a mail server for MX records. That is the whole answer, at a glance. dig's default output is the full DNS message: header flags, the question section, the answer section, authority and additional sections, and a stats footer with query time and server. That verbosity is exactly what you want when debugging, and exactly what you do not want when you just need an IP.

Both tools have a terse mode for scripts and copy-paste: dog example.net --short strips the output down to the record contents, mirroring dig +short. The official README describes dog's short mode as "display nothing but the first result"; Akamai's dog guide describes it as showing only the main contents of the record, like the IP address. In practice, for the everyday queries dog targets, both descriptions converge on the same one-line answer.

How Do You Run DNS-over-TLS and DNS-over-HTTPS with dog?

Encrypted DNS is where dog earns its "modern" label: dog DNS over HTTPS and DNS-over-TLS are first-class flags, not weekend projects. dog example.net -S sends the query over TLS, and dog example.net -H sends it over HTTPS to a DoH-capable resolver. With dig, the same goal requires extra configuration — building or finding a dig with TLS support, or fronting it with a stub resolver like stubby or cloudflared.

Two honest footnotes. First, encrypted transports need a resolver that speaks them — dog will not conjure DoH out of a resolver that only answers on port 53. Second, dog's TLS support is compiled in via a Cargo feature (with_tls, which also gates with_https), so a custom build with features stripped could lack them; the official binaries and packages ship with everything on. If you ever need to query an encrypted endpoint from a browser instead of a terminal, our browser-based DNS lookup tool is the zero-install path.

How Do You Get JSON Output from dog?

For dog JSON output, add -J (or --json): dog emits the whole response as JSON instead of the human-friendly lines. The official README lists JSON output as one of dog's headline features, alongside the colorful output and the encrypted transports, precisely because it makes dog scriptable: a deploy check, a monitoring probe, or a CI step can parse the JSON with jq instead of scraping text. With dig you reach for +json on newer builds or pipe the text through awk and hope the format never changes. For a JSON-first workflow — say, feeding lookup results into an automation pipeline — dog's -J flag is the single biggest ergonomic win over dig.

How Do You Install dog on Ubuntu?

dog has no official apt package for Ubuntu or Debian, so do not apt install dog and expect the DNS client — and treat third-party apt recipes from old blog posts with suspicion. The install paths the project's own README documents are: the dog package on Arch Linux, the dog formula on Homebrew (macOS), the dogdns package on NixOS, pre-compiled binaries from the GitHub releases page for 64-bit Windows, macOS, and Linux, compilation from source with cargo, or the project's Docker container image.

For a dog install on Ubuntu, the practical path is the release binary: download the x86_64-unknown-linux-gnu zip from the releases page, verify its SHA256 against the published SHA256SUMS file (we did exactly this while writing this guide — the checksum matched), and drop the binary in /usr/local/bin. One caveat we hit firsthand: the official v0.1.0 Linux binary links against OpenSSL 1.1 (libssl.so.1.1), which modern Ubuntu releases no longer ship, so the binary will not start until that library is provided. cargo install dog builds against your system's libraries and sidesteps the problem entirely, as do the Homebrew and Arch packages.

1. Pick your path. Homebrew on macOS (brew install dog), the dog package on Arch, the dogdns package on NixOS — or the release binary or cargo on Ubuntu and Debian.
2. Download and verify. Grab the x86_64-unknown-linux-gnu zip from the GitHub releases page and check its SHA256 against the published SHA256SUMS file before you unzip it.
3. Install the binary. Copy dog into /usr/local/bin and confirm with dog --version.
4. Run your first query. Try dog example.com MX @1.1.1.1 — then add -J for JSON output or -H for DNS-over-HTTPS.

Where Can't dog Replace dig?

dog is a lookup tool, not a protocol debugger — and the README never claims otherwise. It cannot walk the delegation chain (dig +trace example.com shows you every server from the root down, which is how you find lame delegations), it cannot do zone transfers (AXFR), it has no batch -f file mode, its DNSSEC debugging is limited, and it has no reverse-lookup flag (dig's -x). If you need a reverse lookup right now, use our reverse DNS lookup tool or dig -x. dog also loses on ubiquity: dig is already on virtually every Linux and Unix box you will ever SSH into, while dog needs installing — which matters the moment you are debugging DNS on someone else's server at 2 a.m. Keep both installed; reach for dog for answers, dig for investigations.

Should You Switch from dig to dog?

Use dog for your everyday lookups — the "what IP is this," "which mail servers," "is the TXT record live yet" questions — where its readable output, sane syntax, native DoT/DoH, and JSON mode save real seconds every time. Keep dig for the protocol work dog cannot do: +trace, AXFR, batch files, DNSSEC chains, and any box where you cannot install software. That is the whole dig vs dog verdict: the dog DNS tool wins daily driving, dig wins debugging.

Two maintenance notes, stated once so you choose with open eyes. Upstream development on ogham/dog has been dormant since about 2021 and its old homepage is offline — but the project is not archived on GitHub, it has a single stable v0.1.0 release with 6,691 stars, and the tool works exactly as documented. If active maintenance matters to you, doggo — a Go reimplementation of the same idea — is actively developed and adds DNS-over-QUIC and DNSCrypt. And if a lookup is about an address rather than a name, our IP lookup tool covers that side of the question.

Sources

• ogham/dog — official GitHub repository and README (command description, tagline, examples, full flag list, install methods, licence EUPL-1.2, v0.1.0, 6,691 stars, 216 forks, not archived) — fetched 2026-11-04
• Akamai — "Use the Linux dog Command to Look Up DNS Records" (output format description, --short behavior, DoT/DoH support, dog-as-dig-alternative framing) — fetched 2026-11-04
• Linux Command Library — dog man page (order-independent SYNOPSIS, no AXFR / no batch -f mode / no +trace equivalent, dormant-since-2021 note, offline homepage note, author ogham, first released 2020) — fetched 2026-11-04
• X-CMD — dog package page (Rust authorship, DoT/DoH flags, -J JSON, "does not implement +trace — fall back to dig", IDNA on by default, doggo comparison table) — fetched 2026-11-04
• Verpex — "Using nslookup and dig to Uncover DNS Issues You Can't See" (dig's structured output, +trace and @server usage, dig's diagnostic role) — fetched 2026-11-04
• DeepWiki — ogham/dog documentation (IDNA default, transport table, verbatim CLI examples) — fetched 2026-11-04
• GitHub releases — dog v0.1.0 linux x86_64 binary, SHA256-verified against published SHA256SUMS by the author of this guide, 2026-11-04

Frequently Asked Questions

Is dog a replacement for dig?

No — dog is a friendlier daily driver, not a full replacement. It handles everyday lookups (A, MX, TXT, NS, AAAA records, custom resolvers, encrypted transports, JSON output) with far more readable output, but dig still owns +trace delegation walks, zone transfers, batch file mode, and deep DNSSEC debugging. Most people who switch keep both installed.

How do I install dog on Ubuntu?

If you searched "dog install ubuntu", here is the short answer: there is no official apt package. Download the pre-compiled Linux binary from the GitHub releases page, verify its SHA256 checksum, and place it in /usr/local/bin — or run cargo install dog to build from source. Note that the official v0.1.0 Linux binary links against OpenSSL 1.1, which modern Ubuntu releases no longer ship; the cargo build avoids that problem.

Does dog support DNS-over-HTTPS?

Yes. dog has native DNS-over-HTTPS via the -H / --https flag and DNS-over-TLS via -S / --tls, built in from the start — no extra tooling required. You still need a resolver that speaks the protocol you choose.

Can dog output JSON for scripts?

Yes. Append -J (or --json) to any query and dog emits the response as JSON, which is easy to parse with jq in deploy checks, monitoring probes, and CI pipelines. That JSON mode is one of dog's biggest ergonomic advantages over dig for automation.

Is dog still maintained?

Mostly dormant, honestly. Upstream commits stalled around 2021 and the project's old homepage is offline, but the GitHub project is not archived, the v0.1.0 release is stable, and everything documented works. If you want an actively developed sibling, doggo — a Go reimplementation of the same idea — adds DNS-over-QUIC and DNSCrypt.