Is Your DNS Private? I Captured My Own DNS Traffic

Short answer: no — plain DNS is not private, and I proved it on my own machine. On October 26, 2026, I ran a packet capture while looking up two domain names the ordinary way, and both names showed up in the capture in plain, readable text. Anyone sitting between your device and the DNS resolver — your internet provider, the Wi-Fi network you're on, or anything else on the path — can see every site you look up, even when the site itself uses HTTPS. Encrypted DNS fixes exactly that leak: six lookups over encrypted DNS produced zero plain DNS packets on the wire. Here's the evidence, and what to do about it.

What DNS does, and why it leaks

Every time you visit a website, your device first asks a DNS resolver "what's the IP address for this name?" With traditional DNS, that question travels over port 53 in plaintext — no encryption at all. HTTPS protects what you do after you reach the site, but it does nothing for the lookup that happens before you get there. The domain name itself is the leak, and it's the part that reveals your browsing habits most directly. This isn't theoretical: it's how DNS was designed in the 1980s, before anyone worried about it. So I decided to capture it instead of just describing it.

How I tested this

The tests ran on an Ubuntu 24.04 VM using dig, tcpdump 4.99.4, and curl 8.5.0. The system resolver was a gateway resolver at 198.19.0.1. I used one made-up test domain (dns-privacy-check-2026.example.org) so the query would be unmistakably mine, plus one real domain (en.wikipedia.org). No other traffic ran during the captures, so every packet in them belonged to my tests.

Test 1: plain DNS queries are readable on the wire

I started tcpdump listening on port 53, then ran two ordinary lookups with dig. The capture caught both queries — and both answers — with the domain names sitting right there in the packet contents:

04:08:28.613200 host0 Out IP 198.19.0.2.53228 > 198.19.0.1.53:
  54430+ [1au] A? dns-privacy-check-2026.example.org. (75)
04:08:28.629031 host0 Out IP 198.19.0.2.49319 > 198.19.0.1.53:
  14038+ [1au] A? en.wikipedia.org. (57)

The full capture was 11 lines covering the two lookups, and a search of it found each queried name multiple times — in the outgoing question and in the returning answer. Nothing was scrambled, hashed, or encrypted. If this capture had been taken anywhere along the path between a device and its resolver, the reader would have learned exactly which sites were visited, and when.

Test 2: encrypted DNS sends nothing over port 53

Next I repeated the exercise with DNS over HTTPS (DoH), the encrypted form of DNS that travels inside an ordinary HTTPS connection to the resolver instead of as a plaintext port-53 packet. I ran three lookups against Cloudflare's DoH service and three against Google's, all while tcpdump was again listening on port 53. The result:

The first run for each provider was the slowest, which is expected — it includes setting up the encrypted connection. And the packet capture for the whole test:

0 packets captured
0 packets received by filter

Six successful lookups, and not one packet on port 53. The queries went out inside TLS-encrypted HTTPS traffic, where a network observer sees a connection to the resolver but not the domain names being asked about. The answers came back correctly too — Cloudflare's DoH response for en.wikipedia.org returned its real address records, so the queries hadn't silently failed.

What encrypted DNS does NOT fix

Encrypted DNS is a real improvement, but it's not an invisibility cloak, and you should know its limits before you switch:

• The resolver still sees your queries. DoH moves your trust from your internet provider to whichever DoH provider you pick. Cloudflare or Google can see the names you look up. Choose a provider whose logging policy you're comfortable with — don't just pick the fastest one and stop thinking.
• The destination IP is still visible. After DNS, your device still connects to the site's IP address, and that address is visible to your network. For a site on a dedicated IP, that alone can give it away. DoH hides the question, not the journey.
• Browser-only settings cover only the browser. Turning on DoH in Firefox protects your web browsing, but other apps on the same device keep using plain system DNS unless you change it at the operating-system level.

There's also a sibling technology, DNS over TLS (DoT), which encrypts DNS on its own dedicated port (853) instead of inside HTTPS. I verified that Cloudflare's DoT port answers a TLS handshake correctly, but I did not run a full DoT query in this test, so I won't claim a DoT speed or behavior result I didn't measure.

How to switch encrypted DNS on

The easiest place to start is your browser. In Firefox, go to Settings → Privacy & Security, scroll to DNS over HTTPS, and turn it on — Mozilla documents the setting in its DNS over HTTPS support page. Chrome and Edge have an equivalent "Secure DNS" setting. If you want coverage beyond the browser, change DNS at the operating-system or router level to a provider that supports DoH or DoT — Cloudflare's 1.1.1.1 setup documentation covers the options, and its DNS over HTTPS documentation explains how the encrypted queries work. After switching, you can verify it the same way I did: a packet capture on port 53 during browsing should stay quiet.

FAQ

Is DNS private by default? No. Traditional DNS queries are sent in plaintext over port 53. My capture showed the queried domain names readable in the packet contents. If you haven't deliberately enabled an encrypted option, assume your lookups are visible to your network path.

Does HTTPS already protect my browsing from this? Only partly. HTTPS encrypts your traffic with the site after you connect, but the DNS lookup happens before that connection and is not covered by it. That's why DNS privacy needs its own fix.

Does encrypted DNS hide my browsing from my internet provider completely? No. It hides the domain names in your DNS queries from the network path, and moves that visibility to your chosen DoH provider instead. Your provider can still see the IP addresses you connect to and the timing and size of your traffic.

Will encrypted DNS slow down my browsing? Not noticeably in my test. Median lookup times were 0.31 seconds (Cloudflare) and 0.39 seconds (Google), with the first run slower because it included the TLS handshake. On a normal connection with a nearby resolver, encrypted lookups are typically tens of milliseconds, not something you'd feel.

Is a VPN a better fix than encrypted DNS? They solve different parts of the problem. A VPN hides your traffic — including DNS, if configured correctly — from your local network and provider, but then the VPN provider sees it instead. Encrypted DNS is free, needs no subscription, and fixes the specific DNS leak. If you already use a trustworthy VPN, it may already handle your DNS; if you don't, DoH is the simplest single step.

Conclusion

Plain DNS broadcasts every site you look up in readable text — I watched my own queries do exactly that in a packet capture. Encrypted DNS removed every trace of those queries from port 53 in my test, at no meaningful speed cost. It doesn't make you anonymous, and it doesn't hide you from the resolver you choose, but it closes a leak that has been open since DNS was invented, and switching it on takes about a minute.

How this article was made

On October 26, 2026, I ran the tests above on an Ubuntu 24.04 VM using dig, tcpdump 4.99.4, and curl 8.5.0. Test 1 captured 2 plain DNS lookups on port 53 and confirmed the queried names in plaintext in the capture. Test 2 ran 6 DNS-over-HTTPS queries (3 via Cloudflare, 3 via Google) with a concurrent port-53 capture that recorded 0 packets, and verified the DoH answers were correct. A TLS handshake to Cloudflare's DNS-over-TLS port (853) was verified separately, but no full DoT query was run, so no DoT performance claim is made. Browser and provider setup steps are documented from the official sources linked above, not from a browser test on this machine. Note that this VM sits behind a gateway resolver (198.19.0.1) that answers from cache, so plain-DNS timing is not compared against DoH timing in this article. This article was drafted with AI assistance, and every number in it comes from the tests above; no result was invented or borrowed.