Stop Wrestling with DNS Tools! dnslookup Handles Every Protocol

Stop Wrestling with DNS Tools! dnslookup Handles Every Protocol

Here's a dirty secret that network engineers won't admit at parties: most DNS debugging is an absolute nightmare. You've got dig for basic queries, kdig for TLS, some random browser dev tools for HTTPS, and don't even get me started on QUIC or DNSCrypt. By the time you've installed seven different utilities, configured their arcane flags, and remembered which one supports what, you've burned 45 minutes just to troubleshoot why your CDN isn't resolving correctly.

Sound familiar? What if I told you there's a single, lightweight command-line tool that eliminates this chaos entirely?

Enter dnslookup — the brainchild of Andrey Meshkov, co-founder of AdGuard and a heavyweight in the DNS privacy space. This deceptively simple utility is what happens when someone who actually understands DNS at a protocol level decides enough is enough. No more tool fragmentation. No more flag memorization marathons. Just one binary that speaks every modern DNS protocol fluently.

In this deep dive, I'll expose why top infrastructure engineers are quietly replacing their entire DNS toolkit with this single Go-powered utility. Whether you're debugging a borked Kubernetes cluster, auditing your DNS privacy setup, or just tired of dig's prehistoric syntax, this guide will transform how you interact with the internet's most critical — and most abused — system.

What is dnslookup?

dnslookup is a command-line utility created by Andrey Meshkov that performs DNS lookups against specified servers. But calling it just another "DNS tool" is like calling a Swiss Army Knife "just a blade." Released under the AdGuard ecosystem, this open-source project has quietly become the go-to solution for developers who need protocol-agnostic DNS debugging without the bloat.

The project lives at github.com/ameshkov/dnslookup and is built in Go — a deliberate choice that delivers single-binary portability across Linux, macOS, Windows, and BSD systems. No dependencies. No Python^{↗ Bright Coding Blog} version hell. No OpenSSL compatibility dances. Just a statically-linked binary that works.

Why is it trending now? Three forces are converging:

1. DNS privacy explosion: With ISPs increasingly monetizing DNS data, encrypted protocols (DoH, DoT, DoQ) have shifted from niche to necessity. dnslookup lets you verify these configurations actually work.
2. Infrastructure complexity: Cloud-native architectures mean DNS resolution paths are longer and more opaque. Engineers need surgical tools to trace every hop.
3. The "one tool" rebellion: Developer tooling is experiencing a renaissance of simplicity. dnslookup embodies this — it does one thing, supports everything, and gets out of your way.

Meshkov's credibility is undeniable. As AdGuard's CTO, he's been in the DNS privacy trenches since before it was trendy. dnslookup isn't theoretical — it's battle-tested against production AdGuard DNS infrastructure handling billions of queries daily.

Key Features That Separate dnslookup from the Pack

Let's dissect what makes this utility genuinely special, not just "another option."

Universal Protocol Support — This is the killer feature. dnslookup handles plain DNS (UDP/TCP), DNS-over-TLS (DoT), DNS-over-HTTPS (DoH with HTTP/2 and HTTP/3), DNS-over-QUIC (DoQ), and DNSCrypt. No other single tool covers this spectrum. Not dig. Not drill. Not dog (the Rust DNS tool). You'd need a Frankenstein setup of 3-4 tools to match this coverage.

Intelligent Protocol Detection — dnslookup uses URL-style scheme prefixes (tls://, https://, quic://) that are instantly readable. Compare this to kdig's +tls flag or dog's --tls option. The URI approach is self-documenting and composes naturally with other tools.

Automatic IP Recognition — Pass an IP without specifying record type, and dnslookup automatically sends a PTR query. This sounds minor until you've typed dig -x for the thousandth time or forgotten the reverse-mapping syntax at 3 AM during an outage.

Machine-Readable Output — Set JSON=1 and get structured data perfect for CI/CD pipelines, monitoring scripts, or feeding into jq for further processing. Traditional tools force you to parse human-oriented output with fragile regex.

Advanced DNS Feature Exposure — dnslookup doesn't hide power behind abstraction. You get direct control over DNSSEC DO bit, EDNS client subnet, EDNS0 padding, custom EDNS options, and certificate verification toggling. These are features that typically require wrestling with dig's +dnssec +subnet=... +padding incantations.

Zero-Config Defaults, Infinite Flexibility — Run dnslookup example.org and it uses your system resolver. Or specify a custom server, protocol, port, authentication — the complexity scales with your needs, not your initial learning curve.

Real-World Use Cases Where dnslookup Dominates

1. Debugging Encrypted DNS Deployments

You've configured your router to use Cloudflare's DoH. But is it actually working? dnslookup lets you verify with surgical precision:

# Verify DoH with HTTP/3 (automatic negotiation)
HTTP3=1 dnslookup example.org https://dns.cloudflare.com/dns-query

# Force HTTP/3 only to test your network path
DNSLOOKUP example.org h3://dns.cloudflare.com/dns-query

No browser certificate inspection. No Wireshark packet capture. Immediate confirmation.

2. Kubernetes and Container Network Debugging

Pod DNS resolution failing? Is it CoreDNS? kube-dns? A custom forwarder? Test each hop:

# Test cluster DNS directly
DNSLOOKUP my-service.default.svc.cluster.local 10.96.0.10

# Verify external resolution through cluster forwarder
DNSLOOKUP google.com tls://10.96.0.10

# Check if DoH upstream from CoreDNS is functional
DNSLOOKUP health.check https://1.1.1.1/dns-query

3. DNS Privacy Auditing and Compliance

Your security team mandates encrypted DNS. Prove compliance:

# Verify no plaintext leakage to ISP resolver
DNSLOOKUP sensitive.internal.com 192.168.1.1  # Your ISP's resolver — should fail or be blocked

# Confirm DoT to corporate resolver works
DNSLOOKUP sensitive.internal.com tls://resolver.corp.internal

# Audit DNSCrypt stamp configuration
DNSLOOKUP test.domain sdns://your-configured-stamp

4. CDN and Geo-Distribution Testing

EDNS Client Subnet (ECS) determines which CDN edge you hit. Test from "virtual" locations:

# Simulate query from Tokyo
SUBNET=1.33.0.0/16 DNSLOOKUP cdn.example.com https://dns.google/dns-query

# Compare with New York
SUBNET=72.229.0.0/16 DNSLOOKUP cdn.example.com https://dns.google/dns-query

This is invaluable for verifying anycast routing and geo-fencing without VPN infrastructure.

5. Automated Monitoring and CI/CD Integration

JSON output + exit codes = perfect automation citizen:

# Health check in Kubernetes liveness probe
JSON=1 DNSLOOKUP critical.api.internal tls://10.0.0.1 | jq -e '.Answer[0].data'

Step-by-Step Installation & Setup Guide

Method 1: Homebrew (macOS/Linux)

The fastest path for most developers:

# Add the tap and install in one shot
brew install ameshkov/tap/dnslookup

# Verify installation
dnslookup --help

This gives you automatic updates via brew upgrade and proper shell completion setup.

Method 2: Go Install (Cross-Platform)

If you have Go 1.20+ installed:

# Install latest directly from source
go install github.com/ameshkov/dnslookup@latest

# Binary lands in $GOPATH/bin or $GOBIN — ensure it's in your $PATH

This method always gets you the bleeding-edge version, ideal if you need recent protocol additions.

Method 3: Pre-built Binaries

For air-gapped environments or specific version pinning:

# Download from releases page (adapt version and OS/arch)
curl -LO https://github.com/ameshkov/dnslookup/releases/download/v1.9.1/dnslookup-linux-amd64-v1.9.1.tar.gz
tar xzf dnslookup-linux-amd64-v1.9.1.tar.gz
sudo mv dnslookup /usr/local/bin/

Method 4: Snap Store

On Ubuntu and snap-enabled systems:

sudo snap install dnslookup

Environment Setup Tips

For daily use, consider shell aliases for common resolvers:

# Add to ~/.bashrc or ~/.zshrc
alias dns-google='dnslookup'
alias dns-cloudflare='dnslookup'
alias dns-adguard='dnslookup'

# Or function for verbose debugging
dns-debug() { VERBOSE=1 dnslookup "$@"; }

REAL Code Examples from the Repository

Let's walk through actual examples from the dnslookup README, with detailed explanations of what's happening under the hood.

Example 1: Basic Resolution with System Defaults

# Uses whatever resolver your OS is configured to use
# (from /etc/resolv.conf on Unix, registry settings on Windows)
dnslookup example.org

What's happening: This is the zero-friction entry point. dnslookup queries your system's configured nameservers via standard UDP port 53. The response includes A records by default. Perfect for quick "is DNS working at all?" checks.

When to use: Verifying basic connectivity, checking if a domain resolves at all, or confirming your local resolver cache behavior.

Example 2: DNS-over-TLS with Pinpoint Control

# Standard DoT — hostname verification against certificate
dnslookup example.org tls://dns.adguard.com

# DoT with explicit IP — bypasses additional A-record lookup for the resolver itself
dnslookup example.org tls://dns.adguard.com 94.140.14.14

What's happening: The tls:// scheme initiates a TLS 1.3 handshake on port 853 (standard DoT port). The first form performs an additional DNS lookup to resolve dns.adguard.com before establishing the encrypted channel — a potential bootstrap problem if your system resolver is compromised. The second form eliminates this by providing the IP directly, making it ideal for captive portal or hostile network scenarios.

Critical detail: The 94.140.14.14 is AdGuard's anycast address. If you run your own DoT resolver, this pattern lets you specify its exact IP without publishing DNS records.

Example 3: DNS-over-HTTPS with HTTP/3 Negotiation

# Enable HTTP/3 with automatic fallback to HTTP/2
HTTP3=1 dnslookup example.org https://dns.google/dns-query

# Force HTTP/3 only — fails if path doesn't support it
dnslookup example.org h3://dns.google/dns-query

What's happening: These examples showcase dnslookup's QUIC and HTTP/3 support. The first uses an environment variable to prefer HTTP/3 but gracefully degrade. The second uses the h3:// scheme to mandate HTTP/3, failing entirely if unavailable.

Why this matters: HTTP/3 over QUIC eliminates head-of-line blocking and reduces connection establishment latency — crucial for high-performance DNS resolution. Google's dns.google supports this, but many corporate proxies don't. The h3:// form is perfect for testing whether your network path actually permits QUIC (many firewalls block UDP 443).

Example 4: DNSCrypt with Stamp Parsing

# Using a DNSCrypt stamp (contains all connection parameters encoded)
dnslookup example.org sdns://AQIAAAAAAAAAFDE3Ni4xMDMuMTMwLjEzMDo1NDQzINErR_JS3PLCu_iZEIbq95zkSV2LFsigxDIuUso_OQhzIjIuZG5zY3J5cHQuZGVmYXVsdC5uczEuYWRndWFyZC5jb20

What's happening: DNSCrypt stamps are Base64-encoded blobs containing the resolver's IP, port, provider name, and public key. dnslookup parses this internally — no manual parameter extraction needed.

The alternative form shows explicit parameters for comparison:

# IP:port, provider name, public key (hex)
dnslookup example.org 176.103.130.130:5443 2.dnscrypt.default.ns1.adguard.com D12B:47F2:52DC:F2C2:BBF8:9910:86EA:F79C:E449:5D8B:16C8:A0C4:322E:52CA:3F39:0873

When to use: DNSCrypt is particularly valuable in censorship-heavy regions where DoH/DoT endpoints are actively blocked. The protocol's design resists fingerprinting and active probing better than TLS-based alternatives.

Example 5: Advanced EDNS Manipulation for Geo-Testing

# Combine multiple EDNS options: subnet, padding, specific record type
RRTYPE=TXT SUBNET=1.1.1.1/24 PAD=1 dnslookup o-o.myaddr.l.google.com tls://8.8.8.8

What's happening: This is power-user territory. We're querying Google's o-o.myaddr.l.google.com — a special domain that returns your detected IP in a TXT record — with three simultaneous manipulations:

• RRTYPE=TXT: Request TXT records instead of default A
• SUBNET=1.1.1.1/24: Spoof EDNS Client Subnet as Cloudflare's anycast
• PAD=1: Enable EDNS0 padding to obscure query length (privacy protection against traffic analysis)

The result: Google's resolver sees a query "from" Cloudflare's network and tells you what IP it thinks you're coming from. This validates whether ECS propagation is working and whether padding is applied correctly.

Advanced Usage & Best Practices

Scripting with JSON Output

Always use JSON=1 for programmatic consumption. The structure is stable and includes timing data:

# Extract just the answer in a pipeline
JSON=1 dnslookup api.github.com https://1.1.1.1/dns-query | jq -r '.Answer[0].data'

Certificate Verification Control

VERIFY=0 disables TLS certificate checks. Never use in production, but essential for testing internal resolvers with self-signed certificates during development:

# Test internal DoT before proper PKI deployment
VERIFY=0 dnslookup staging.internal tls://10.0.0.50

DNSSEC Validation

Set DNSSEC=1 to request DNSSEC records. The response includes RRSIGs if the zone is signed. Combine with VERBOSE=1 to see validation chain details:

DNSSEC=1 VERBOSE=1 dnslookup dnssec-failed.org tls://8.8.8.8

Performance Benchmarking

Use VERBOSE=1 to see query timing. For systematic comparison:

# Time different protocols to same resolver
time dnslookup test.com 8.8.8.8
time dnslookup test.com tls://8.8.8.8
time dnslookup test.com https://dns.google/dns-query

Comparison with Alternatives

Verdict: dnslookup is the only tool covering the complete modern DNS protocol landscape in a single, portable binary. dig remains ubiquitous but is architecturally frozen in the 1990s. kdig is powerful but Knot DNS-specific and complex. dog is elegant but lacks encrypted protocol breadth.

FAQ

Q: Does dnslookup replace dig completely? A: For 95% of use cases, yes. The 5% edge involves dig's +trace functionality for iterative resolution debugging, which dnslookup doesn't replicate. Keep dig in your toolkit, but reach for dnslookup first.

Q: How do I debug why DoH queries fail? A: Start with VERBOSE=1 to see TLS handshake details. Then try VERIFY=0 to isolate certificate issues. For HTTP-level debugging, HTTP3=1 vs h3:// helps identify QUIC path problems.

Q: Can I use dnslookup in production monitoring? A: Absolutely. The JSON output and predictable exit codes make it ideal for Nagios, Zabbix, or custom health checks. Just pin to a specific version rather than @latest.

Q: Why does DNS-over-QUIC matter if I have DoH? A: DoQ eliminates TCP/TLS overhead entirely, reducing latency on high-RTT connections. It's also harder to fingerprint and block than HTTPS traffic. Early adoption, but strategically important.

Q: How do I test DNSSEC validation? A: Use DNSSEC=1 with known test domains: dnssec-failed.org (should fail validation), dnssec-deployment.org (should succeed). Compare against multiple resolvers.

Q: Is there Windows support? A: Yes — pre-built binaries are available, or use go install. The tool works identically across platforms.

Q: Can I contribute or report issues? A: The project is actively maintained at github.com/ameshkov/dnslookup. Issues and PRs are welcome.

Conclusion

DNS is the invisible backbone of every digital interaction you make, yet our tools for understanding it have been stuck in a bygone era. dnslookup represents a rare combination of radical simplicity and comprehensive power — the kind of tool that makes you genuinely angry you didn't discover it sooner.

After months of using dnslookup across Kubernetes debugging, CDN verification, and privacy auditing, I've uninstalled kdig, stopped compiling dog, and only keep dig around for +trace edge cases. One binary. Every protocol. Instant clarity.

The network engineering world is quietly standardizing on this tool. Don't be the last one to make the switch.

Ready to stop wrestling with DNS? Grab dnslookup now from the official GitHub repository — star it, install it, and never look back. Your future 3 AM outage self will thank you.