How to Use Doggo: A Beginner's Guide to the DNS Client for Humans
CodexFuse Team · 2026-11-02T09:47:13.238Z · 12 min read min read
Doggo is the human-friendly DNS client: clean tables, encrypted DNS, and JSON output. Learn install, first lookup, nameservers, DoH, and the ndots rule.
How to Use Doggo: A Beginner's Guide to the DNS Client for Humans
Learning how to use doggo takes about ten minutes, and it will change how you debug DNS forever. Run doggo example.com and you get a neat color-coded table with the domain's A record instead of the wall of raw protocol output that dig throws at you. Doggo is a modern command-line DNS client written in Go that speaks the newest DNS protocols — DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC, and DNSCrypt — alongside plain old UDP port 53.
If you have never looked up a DNS record before, start with our DNS lookup guide, which explains what lookups are and when you need them. This doggo tutorial is the product guide: the doggo dns workflow from install through the ndots rule, end to end.
What Is Doggo, Exactly?
Doggo is a modern command-line DNS client written in Golang. The author's own description says it best: doggo is a modern command-line DNS client (like dig) that outputs information in a neat concise manner and supports protocols like DoH, DoT, DoQ, and DNSCrypt. Its tagline is "command-line DNS client for humans." It is free and open source under the GPL-3.0 license, and the current release as of this writing is v1.4.2, published 2026-10-22. The name is a pun: it was inspired by the Rust DNS client dog, and dog plus go makes doggo.
How Do You Install Doggo?
Installation is a single command on most systems. A doggo install takes under a minute, and the README documents every route. Pick the one that matches your setup. Most readers will run this on a laptop or a server — if yours is a server, our what is VPS hosting guide explains the environment.
| Platform or method | Command (verbatim from the README) |
|---|---|
| Linux / macOS (recommended) | curl -fsSL https://raw.githubusercontent.com/mr-karan/doggo/main/install.sh | sh |
| macOS via Homebrew | brew install doggo |
| Arch Linux | pacman -S doggo |
| Nix | nix profile install nixpkgs#doggo |
| Mise | mise use -g doggo@latest |
| Windows via Scoop | scoop install doggo |
| Windows via Winget | winget install doggo |
| Go toolchain | go install github.com/mr-karan/doggo/cmd/doggo@latest |
| Docker | docker run --rm ghcr.io/mr-karan/doggo:latest example.com |
Verify the install the same way we did for this guide, against the official release binary: run doggo --version and you should see v1.4.2 with the build date. On this machine the fresh download reported v1.4.2 (021e46c 2026-10-22T06:19:44Z), matching the GitHub Releases API.
What Does Your First Lookup Look Like?
Your first lookup is one command: doggo example.com. That is the README's documented quick start, and it is all you need to see doggo's signature output.
doggo example.com
The result is a human-readable table with six columns: NAME, TYPE, CLASS, TTL, ADDRESS, and NAMESERVER. A documented sample from the DNS-tooling roundup at syslog.me shows what it looks like: mrkaran.dev. A IN 20s 13.250.205.9 127.0.0.1:53 — one row per answer, with the TTL shown as a friendly duration like 20s instead of a raw integer.
We ran this exact command against the official v1.4.2 binary to write this guide, and the layout came back exactly as documented: the six-column table, the duration-style TTLs, and the resolver address in the final column. On our test network the resolver reported was the sandbox's own stub, so your ADDRESS column will show your network's real answers — the format is the point, and it matches the documentation.
A records come back with an IP address in the ADDRESS column. That is the address your browser would connect to. If you want to understand what those numbers mean, our IP address explainer covers it.
How Do You Query MX, TXT, and Other Record Types?
You put the record type after the domain: doggo github.com MX queries the MX records for github.com. The README's own example is doggo MX github.com @9.9.9.9, which adds a specific nameserver on top.
The classic three beginner record types are A (the IP address of the host), MX (where mail for the domain goes), and TXT (freeform text, used for SPF and domain verification). Try all three on a domain you own:
doggo example.com MX doggo example.com TXT
If you need everything at once, doggo has an --any flag that queries all supported record types — A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, TXT, and CAA — in a single invocation. And for full control you can pass explicit flags: doggo -q example.com -t CNAME -n 9.9.9.9 does the same job with named arguments.
How Do You Pick Which Nameserver Answers?
Doggo answers the question "who do you ask?" with the @ prefix. By default it uses your system's resolver from /etc/resolv.conf. Add @9.9.9.9 to ask Quad9 instead, or @1.1.1.1 for Cloudflare.
The killer feature is asking several resolvers in one command. The documented syntax lets you list them space-separated:
doggo example.com @1.1.1.1 @8.8.8.8 @9.9.9.9
Doggo then decides how to use them based on the resolver strategy. The README's sample config shows strategy = "first" as an option, and the three documented strategies are all (query every nameserver), random (pick one at random), and first (use the first in the list). Set it with --strategy=all. Comparing answers across resolvers is the fastest way to spot a propagation problem: if Cloudflare has your new record but Google does not, you know the change is still propagating.
Two advanced one-liners belong in this section. doggo example.com --trace follows the delegation chain iteratively from the root servers down to the authoritative answer, which is how you find a broken delegation. doggo --reverse 8.8.8.8 performs a reverse lookup, showing the domain tied to an IP. If path problems rather than name problems are what you are chasing, our Trippy beginner guide covers tracing network paths the same readable way doggo handles names.
What Are DoT, DoH, DoQ, and DNSCrypt in Doggo?
Encrypted DNS is doggo's headline feature. Plain DNS travels over UDP port 53 in the clear, which means anyone on the path can read or alter it. Doggo lets you pick an encrypted transport simply by prefixing the nameserver with a URL scheme — no config file, no daemon, just the query.
| Protocol | Syntax | What happens |
|---|---|---|
| Plain UDP (default) | doggo example.com @1.1.1.1 | Standard DNS on port 53, unencrypted |
| TCP | doggo example.com @tcp://1.1.1.1 | DNS over TCP on port 53 |
| DNS-over-TLS (DoT) | doggo example.com @tls://1.1.1.1 | Encrypted query to port 853 |
| DNS-over-HTTPS (DoH) | doggo example.com @https://cloudflare-dns.com/dns-query | Encrypted query inside an HTTPS request |
| DNS-over-QUIC (DoQ) | doggo example.com @quic://1.1.1.1 | Encrypted query over the QUIC transport |
| DNSCrypt / stamped DoH | doggo example.com @sdns://<stamp> | DNSCrypt or DoH via a DNS stamp |
The DoH line in the table is the README's own example, quoted verbatim. A doggo doh query is the one to reach for on untrusted networks like coffee-shop Wi-Fi: the query looks like ordinary HTTPS traffic. For the strictest setup, pair DoH with HTTP/3 using the --http3 flag — the README notes that HTTP/3 must be paired with a persistent HTTPS (DoH) nameserver.
One honest note from our testing: we ran doggo's encrypted protocols against the documentation, not against a live encrypted server, because the sandbox network this guide was verified on does not allow direct outbound encrypted-DNS connections (the DoH attempt timed out at the network edge). The syntax above is quoted from the project's own docs and README, so it is accurate — the queries themselves simply need a network with real DNS egress.
How Do You Get JSON Output for Scripts?
Add --json and the human table becomes machine-readable JSON. A doggo json query is one flag away, and it is the feature that makes doggo a scripting tool, not just a prettier dig.
doggo example.com --json | jq '.responses[0].answers[].address'
That is the README's documented pattern: the JSON has a responses array, each with an answers array, and jq pulls the addresses out. If you monitor domains — checking that your A records still point where they should — this one-liner is the building block: run it on a schedule, compare the addresses, alert when they drift.
What Is the ndots Rule in Kubernetes?
The ndots lesson is the reason doggo exists, and it is the section Kubernetes users should read twice. Inside a Kubernetes pod, the resolver tries each search domain in turn before giving up, and the number of dots a name must have before it is treated as absolute is controlled by the ndots setting (default 5). The result: a query for a short name can fire off several wasteful search-domain expansions before it ever resolves.
The doggo author hit exactly this in 2021 while working with many Kubernetes clusters. His words on the Hacker News Show HN thread: "I pretty much did this as a learning/hobby side project. Back in 2021, I was dealing with a lot of K8s clusters and had recently learnt what about ndots. That prompted me to build an easy to use DNS client which can avoid surprises about the host environment."
Doggo exposes the fix directly. The doggo ndots flag exists because of this exact story: --ndots flag overrides the value (it takes the value from /etc/resolv.conf when you use the system nameserver, and defaults to 1 otherwise), and --search toggles whether the resolv.conf search list is used at all (--search=false disables it). So doggo myservice --ndots=1 --search=false asks for exactly what you typed, with no search-domain guessing and no surprise expansion — which is precisely the behavior you want when debugging DNS inside a cluster.
doggo vs dig: What's the Difference?
Doggo is not a dig replacement in the protocol sense — both speak DNS — but it is a different experience, and one different capability. The honest comparison:
| dig | doggo | |
|---|---|---|
| Output | Raw protocol sections (HEADER, QUESTION, ANSWER, AUTHORITY, ADDITIONAL) | Color-coded human table; --json for machines |
| Encrypted transports | Needs extra tooling (stubby, dnscrypt-proxy) | Built in: DoT, DoH, DoQ, DNSCrypt via @ syntax |
| Multiple resolvers | One nameserver per invocation (@server) | Several in one command with --strategy |
| Learning curve | Flags like +noall +answer to memorize | Reads like a sentence: doggo example.com MX @9.9.9.9 |
| Availability | Everywhere (bind-utils/dnsutils) | One install away (v1.4.2 as of 2026-10-22) |
One disambiguation, stated once: doggo is inspired by ogham/dog, the Rust DNS client by Benjamin D. Esham. The README says it plainly: "It's totally inspired by dog which is written in Rust. I wanted to add some features to it but since I don't know Rust, I found it as a nice opportunity to experiment with writing a DNS Client from scratch in Go myself. Hence the name dog + go => doggo." They are sibling projects with the same spirit, not rivals.
7 Beginner Mistakes With Doggo
| Mistake | What actually happens |
|---|---|
| Reading the table's ADDRESS as gospel on a test network | Sandbox and VPN resolvers can rewrite answers; we saw our own test network's stub resolver in the NAMESERVER column. Verify against @1.1.1.1 when in doubt. |
| Assuming the browser web interface is the tutorial | doggo.mrkaran.dev is a handy query form, but it is one line in the README — the CLI is the product. |
| Forgetting the @ before a nameserver | doggo example.com 1.1.1.1 treats 1.1.1.1 as another query, not a resolver. The @ is the whole mechanism. |
| Using --search defaults inside Kubernetes | The search list fires ndots expansions you did not ask for. Use --ndots and --search=false when debugging cluster DNS. |
| Expecting dig's sections in the output | Doggo deliberately hides the AUTHORITY/ADDITIONAL sections. Reach for dig when you need the raw protocol view. |
| Copying install commands from AI-written guides | We found a popular AI-generated doggo guide listing install commands the README never documents (wrong Docker image, wrong subcommand). Verify against github.com/mr-karan/doggo. |
| Promising doggo features it does not have | There is no config wizard and no interactive mode; everything flows through flags, a TOML config file, and DOGGO_ environment variables. |
Sources
- mr-karan/doggo GitHub repository — README: tagline, install methods, quick-start examples, DoH example, JSON example, ogham/dog inspiration quote, GPL-3.0 license, config file documentation (github.com/mr-karan/doggo)
- GitHub Releases API for mr-karan/doggo — v1.4.2 published 2026-10-22, repo created 2020-12-09 (api.github.com/repos/mr-karan/doggo/releases/latest)
- Hacker News Show HN thread — author's comment on the ndots origin story, quoted verbatim (news.ycombinator.com/item?id=40847699)
- mrkaran.dev blog, "ndots in Kubernetes" (2020-12-24) — corroborates the origin story: "I've worked on a DNS Client which lets you tweak these params on the fly" (mrkaran.dev/posts/ndots-kubernetes)
- doggo.mrkaran.dev — the web interface: browser query form with record-type, nameserver, flags, and EDNS options (doggo.mrkaran.dev)
- doggo.mrkaran.dev/docs/ — feature list: IDN punycode, shell completions, debug mode, response timing, query flags (doggo.mrkaran.dev/docs)
- syslog.me, "More DNS tooling" (2023-10-23) — documented sample table output with NAME/TYPE/CLASS/TTL/ADDRESS/NAMESERVER columns (syslog.me/2023/10/23/more-dns-tooling)
- DeepWiki mr-karan/doggo command-line-interface page — @ nameserver syntax and explicit -q/-t/-n flags, sourced from the project's parse code (deepwiki.com/mr-karan/doggo/2.2-command-line-interface)
- x-cmd doggo installer page — multiple-nameserver syntax and transport URL examples (x-cmd.com/install/doggo)
Frequently Asked Questions
Is doggo better than dig?
For humans, yes; for protocol debugging, keep dig around. Doggo wins on readable output, built-in encrypted DNS (DoH, DoT, DoQ, DNSCrypt), and multi-resolver queries in one command. Dig wins on ubiquity and raw protocol detail like the AUTHORITY and ADDITIONAL sections, which doggo hides on purpose.
How do I use doggo with DNS-over-HTTPS?
Prefix a DoH endpoint with @https:// — the README's own example is doggo example.com @https://cloudflare-dns.com/dns-query. Add --http3 to run that DoH query over HTTP/3. No config file or extra daemon is needed.
What does the ndots setting do in doggo?
It controls how many dots a hostname needs before the resolver treats it as absolute instead of trying search domains first. Doggo reads it from /etc/resolv.conf with the system nameserver and defaults to 1 otherwise. Override it with --ndots, and disable the search list entirely with --search=false — the combination Kubernetes users need when debugging cluster DNS.
Does doggo work on Windows?
Yes. The README documents both Scoop (scoop install doggo) and Winget (winget install doggo) installs, plus prebuilt Windows binaries on the releases page.
Is doggo free to use?
Yes. Doggo is open source under the GPL-3.0 license, hosted at github.com/mr-karan/doggo. The current release as of this writing is v1.4.2, published 2026-10-22.
