A closer look at the DNS traffic on your machine

There's a new open-source utility for anyone who has ever wondered what DNS queries their computer is silently making. dnspeep, written in about 250 lines of Rust, captures DNS queries and responses in real time and prints them in a readable, one-line-per-transaction format.

The tool runs as root because it relies on libpcap, the same packet-capture library that powers tcpdump. Prebuilt binaries are available for Linux (x86) and macOS, or you can build from source on GitHub.

wget https://github.com/jvns/dnspeep/releases/download/v0.1.0/dnspeep-linux.tar.gz
tar -xf dnspeep-linux.tar.gz
sudo ./dnspeep

wget https://github.com/jvns/dnspeep/releases/download/v0.1.0/dnspeep-macos.tar.gz
tar -xf dnspeep-macos.tar.gz
sudo ./dnspeep

The output shows each query and its matching response together:

$ sudo dnspeep
query   name                 server IP      response
A       firefox.com          192.168.1.1    A: 44.235.246.155, A: 44.236.72.93, A: 44.236.48.31
AAAA    firefox.com          192.168.1.1    NOERROR
A       bolt.dropbox.com     192.168.1.1    CNAME: bolt.v.dropbox.com, A: 162.125.19.131

For example, those lines above came from visiting neopets.com in a browser, plus a background bolt.dropbox.com lookup from a running Dropbox agent.

Why bother?

DNS can feel abstract when you can't see it happening. Watching real queries and responses makes the system tangible, and it also gives you a practical debugging angle. When you suspect a DNS problem, you can stop guessing and look directly at what your resolver is actually returning.

The tool also exposes which pieces of software are phoning home. The author noted that something on their machine periodically queries ping.manjaro.org, presumably to check connectivity. More strikingly, a friend used dnspeep to uncover forgotten corporate monitoring software from a previous job.

Why not just use tcpdump?

tcpdump does parse DNS packets, but its output is dense and awkward for casual inspection. A typical query line looks like:

11:36:38.973512 wlp3s0 Out IP 192.168.1.181.42281 > 192.168.1.1.53: 56271+ A? incoming.telemetry.mozilla.org. (48)
11:36:38.996060 wlp3s0 In  IP 192.168.1.1.53 > 192.168.1.181.42281: 56271 3/0/0 CNAME telemetry-incoming.r53-2.services.mozilla.com., CNAME prod.data-ingestion.prod.dataops.mozgcp.net., A 35.244.247.133 (180)

Breaking that down: A? indicates a type A query, the domain name follows, 56271 is the query ID, 192.168.1.181.42281 and 192.168.1.1.53 are source and destination IP/port pairs, and (48) is the DNS packet length. The response line carries the same ID, followed by 3/0/0 (three answers, zero authority records, zero additional records) and the answer list: two CNAMEs and one A record.

The real pain point is that you have to manually match requests to responses by ID, and they aren't always adjacent lines. That's precisely the kind of bookkeeping a computer should do, which is what dnspeep automates while stripping out the extraneous detail.

Development hurdles

Writing the tool surfaced several technical snags:

  • The pcap crate needed a one-line patch to work correctly with Tokio on macOS, a fix that took hours to identify.
  • Linux distributions ship different versions of libpcap.so, making dynamically linked binaries impractical to distribute. The solution was to statically link libpcap.a into the Linux build.
  • The dns_parser crate handles only the most common DNS query types, so some queries are unsupported. Switching to a more complete parser is on the roadmap.
  • Since pcap delivers raw bytes including the Ethernet frame, the code has to strip the right number of leading bytes to reach the IP header. The author suspects some edge cases remain unhandled.

Naming also proved tricky given the crowded field of DNS tools (dnsspy, dnssnoop, dnssniff, dnswatch). The author settled on dnspeep after cycling through synonyms for "spy."

One limitation: the utility cannot tell you which process initiated a query. For that, the eBPF-based dnssnoop tool exists, though the author hasn't tested it yet.

Expect bugs

The tool has seen only light testing on Linux and macOS, and at least one known bug stems from incomplete DNS query-type support. The failure mode is benign, though: libpcap's read-only interface means the worst case is an error message or crash, not corrupted traffic.

dnspeep is part of a broader effort to make DNS more approachable. The author has also published a simple DNS lookup web page and an interactive trace tool that shows what happens behind the scenes during a query. The goal is to give newcomers friendlier windows into DNS than the raw output of traditional utilities, making the protocol something anyone can observe rather than a mystery reserved for tcpdump experts.