DNS: the link no one hardens

Network audit of an industrial SME, one morning. I plug a passive probe into the mirror port of the main switch and watch the traffic go by. Everything’s HTTPS, the HR director is proud of his brand-new £16,000 firewall. Except that on port 53, in the clear, scrolls the company’s complete browsing: the domain of the law firm consulted the day before, the website of the potential acquirer, the bank, the occupational physician, the competitor. In twenty minutes, I reconstructed a confidential M&A file without decrypting a single connection. The DNS gave me everything.

The usual trap

Everyone has internalized that HTTPSSecure HTTP encrypting browser-server communication via TLS.See glossary protects. The green padlock, the “s” in the address bar, the internal training that repeats “check that the site is HTTPS”: the reflex is acquired. And it’s correct — the content of your exchanges is indeed encrypted between your browser and the server. The problem is that this reflex stops exactly where it should start asking questions. Nobody wonders what happens before the HTTPS connection. And before, there’s DNSSystem resolving domain names to IP addresses. Vastly underestimated surveillance vector.See glossary.

Before your browser opens an encrypted connection to online-banking.com, it has to translate that name into an IP address. This translation, in the default configuration of practically every device on the planet, goes out in the clear, on port 53, toward the resolver of your ISPSystem resolving domain names to IP addresses. Vastly underestimated surveillance vector.See glossary or mobile carrier. No encryption, no authentication, no confidentiality. It’s the 1987 protocol, and it’s still the default in 2026. The content of your exchange with the bank is protected. The fact that you’re talking to that bank, at what time, how often, from which device: visible to everyone on the path.

The dominant discourse on “network security” sustains this hole. People sell next-generation firewalls, web gateways, five-figure traffic-inspection solutions, while the most elementary leak channel stays wide open. Worse: many of these appliances force DNS to pass through them in the clear, under the pretext of “visibility.” The “I’ve got HTTPS, I’m fine” reflex has become a collective blind spot. DNS is the link no one hardens because no one looks at it — and that’s precisely what makes it a surveillance vector as profitable as it is for anyone who knows how to listen.

The real threat model: what DNS reveals, and to whom

Think of DNS as the internet’s directory. Every time a device wants to reach a service, it queries a resolver: “what is the address of this domain?” This question, repeated thousands of times a day per device, draws a portrait of fearsome precision. Not the content — the intent. And intent is more than enough.

In unencrypted DNS, here’s what’s readable to anyone listening: every domain you visit, the exact timestamp, the frequency. These aren’t only the sites you open by hand in the browser. Your mobile apps make DNS requests constantly — your mail client queries the server every minute, your encrypted messenger resolves its relay domain, your connected objects call their cloud, your automatic updates contact their servers. DNS betrays the list of your applications, your sleep habits (the time of the first request in the morning), your work rhythms, the banking and medical services you use, sometimes your implicit location via the choice of regional resolvers and CDNsSystem resolving domain names to IP addresses. Vastly underestimated surveillance vector.See glossary.

Who sees this data? Three actors, at the minimum. Your ISP or mobile carrier first, which operates the default resolver — in France and across the Union, connection metadata is legally retained for a year, and several ISPs commercially exploit this data or redirect non-existent domains toward their own ad pages. Next, anyone listening on the local network: the hotel Wi-Fi, the café, the airport, the conference room, wherever you control nothing and port 53 passes in the clear under the noses of all the other clients. Finally, your resolver itself, whatever it is — choosing a resolver means choosing whom you entrust with the entirety of your browsing history.

There’s a subtlety people forget. Even when you encrypt DNS, the TLSTransport encryption protocol, basis of HTTPS and modern web security.See glossary handshake still contains the Server Name Indication (SNI) in the clear — the domain name, visible to any network observer. The Encrypted Client Hello (ECH) mechanism, standardized via RFC 9460, encrypts this SNI, but its deployment remains partial in 2026 and depends on the target site supporting it server-side. In other words: hardening DNS is necessary, but it’s only part of the picture. DNS nonetheless remains the broadest, most systematic, and simplest leak vector to plug.

Another point I have to hammer home in audits, because it comes up constantly: cleartext DNS isn’t only a confidentiality problem, it’s also an integrity problem. On unauthenticated port 53, any actor on the network path can answer in your place — that’s DNS spoofing. You ask for your bank’s address, an attacker on the hotel Wi-Fi answers with the IP of their phishing server, and your browser obediently goes there. HTTPS and certificate validation catch part of the blow (the fake site won’t have the right certificate), but not always, and not for the many flows that don’t strictly validate the certificate. Encrypting and authenticating DNS closes this door at the same time as it closes the eavesdropping. Two problems, one measure.

And we have to get past the idea that “it doesn’t concern me, I’ve got nothing to hide.” The real threat model isn’t “someone reads my Google searches.” It’s an aggregate: your carrier resells a behavioral profile, a data broker cross-references it with other sources, an insurer or a potential employer buys it, a state subpoenas it, or a targeted attacker reconstructs your habits to prepare a credible spear phishingTargeted phishing on a specific person, built from their OSINT profile.See glossary. The isolated DNS request is harmless. The complete DNS flow over six months is a dossier.

The right approach: Do53, DoT, DoH, and the right resolver

The shift is one of the most cost-effective in all of operational security: little effort, immediate effect, free in the majority of cases. But you have to understand the three modes so you don’t fight the wrong battle.

Do53 — classic DNS, port 53, in the clear. It’s the default on all your devices. No encryption, no authentication of the response. Your resolver sees your requests in the clear, and so does any appliance on the network path. This is what you want to leave.

DoTDoH variant using direct TLS on port 853.See glossary — DNS over TLS, port 853. Requests are encrypted inside a dedicated TLS tunnel, defined by RFC 7858. No one can read them in transit anymore. The drawback: port 853 is identifiable as “encrypted DNS traffic.” A hostile network appliance can block it, which forces some systems to fall back to the clear on port 53. It’s the native and cleanest mode on mobile (Android’s “Private DNS”), because it applies to the entire system.

DoHProtocol encrypting DNS requests inside HTTPS, hiding them from the ISP.See glossary — DNS over HTTPS, port 443. Requests are encapsulated in standard HTTPS traffic, per RFC 8484. Double advantage: encryption, and above all indistinguishability — your DNS requests look like any web connection. Blocking DoH without breaking all HTTPS traffic is extremely difficult, which makes it the weapon of choice against active network surveillance. It’s the preferred mode in the browser and in contexts where the local network is hostile.

Don’t confuse all this with DNSSEC, which often comes up in the discussion. DNSSEC cryptographically signs DNS responses — it guarantees integrity (the response hasn’t been falsified en route), but encrypts nothing. DNSSEC and DoH/DoT are complementary, not competitors: one protects against falsification, the others against eavesdropping.

Once the mode is chosen, the real decision remains: the resolver. It’s the entity that makes the actual requests for you, therefore the one that sees everything. Changing it is the most impactful action for the least effort.

• Quad9System resolving domain names to IP addresses. Vastly underestimated surveillance vector.See glossary (9.9.9.9) — operated by a Swiss non-profit foundation, documented no-logs policy, filtering of malicious domains active by default (aggregated threat database), DoH and DoT support. My default choice for anyone who wants security without configuration. If I had to recommend a single resolver to someone who doesn’t want to set anything, it’s this one.
• Mullvad DNS — oriented toward pure privacy. If you already use Mullvad VPN, DNS goes through the tunnel. Mullvad also offers public resolvers usable on their own, with variants filtering ads and tracking. No security filtering by default: a privacy choice, not a security one.
• NextDNSSystem resolving domain names to IP addresses. Vastly underestimated surveillance vector.See glossary — the configurable one. You create a profile: ad, tracking, malware, category blocking. Optional logs — enable them to audit your traffic, disable them entirely. Freemium: 300,000 requests/month free, then around €2/month. Excellent for families and SMEs who want controlled visibility.
• CloudflareSystem resolving domain names to IP addresses. Vastly underestimated surveillance vector.See glossary (1.1.1.1) — the fastest in latency, partially-audited no-logs claim. Caveat: Cloudflare is an American megacorp that already hosts a massive fraction of the web. Their visibility over flows is colossal. Acceptable for the general public, less so for anyone wanting to avoid concentrating risk with a single actor subject to US law.
• Default ISP — to flee. Commercial profiling, advertising redirects, legal retention. It’s exactly the resolver you want to leave.
• Self-hosted (Unbound + Pi-hole) — total control. Unbound resolves recursively directly with the root servers, no third party. Pi-hole filters ads and tracking locally for the whole network. You carry the maintenance, and it doesn’t follow you on the move (except via a return VPN). The right choice for the hardened home, not for travel.

A word on self-hosting, because that’s where people fool themselves the most. Pi-hole is a local resolver that consults blocklists: when a device asks for the IP of doubleclick.net or a telemetry domain, Pi-hole answers “NXDOMAIN” and the connection never happens. It’s powerful — it blocks ads and tracking at the network level for all devices, including the smart TV, the console, and the connected objects you can’t configure individually, and it gives you complete visibility over what each device calls. But Pi-hole, alone, encrypts nothing. Everything it doesn’t block goes out in the clear toward your ISP. The combination that actually stands up is Pi-hole for filtering, Unbound behind it for direct recursive resolution, and an encrypted upstream (DoT) for the requests that go out anyway. More complex to set up, but it’s the only arrangement that gives you filtering, confidentiality, and control at once. And keep in mind that some apps with hard-coded DoH (Firefox, certain Google services) bypass Pi-hole purely and simply — network filtering has its limits against applications that decide on their own resolver.

What this means concretely

Mistakes we see all the time

• Configuring DoH in the browser only. Partial by construction. The mail client, the mobile apps, the system services, and the connected objects carry on with the default resolver in the clear. You tick a box and think you’re covered for 100% of the traffic when you cover a fraction.
• Believing Pi-hole encrypts requests. Pi-hole filters, it doesn’t encrypt. Without a configured DoHProtocol encrypting DNS requests inside HTTPS, hiding them from the ISP.See glossary or DoTDoH variant using direct TLS on port 853.See glossary upstream, everything Pi-hole doesn’t block — that is, the great majority — goes out in the clear toward your ISP. Pi-hole without an encrypted upstream is ad filtering, not confidentiality.
• Forgetting DNS when travelling. A DoH config set up at home doesn’t apply on 4G or hotel Wi-Fi if it lives only in the browser. Abroad, the local carrier’s resolver takes back control. Only system-level DNS (iOS profile, Android Private DNS) travels with you.
• Leaving the SMS or the ISP as the resolver “because it works.” It works, yes, and that’s exactly the problem: it works while exposing your complete browsing to an actor that retains it for a year and exploits it commercially.
• Never testing. Many people think they’re on DoH and are actually leaking toward the ISP’s resolver. dnsleaktest.com(opens in a new tab) and ipleak.net(opens in a new tab) settle the question in ten seconds. An unverified DNS config is a hypothesis, not a protection.

Actionable checklist

• N1 Enable DoH or DoT at the system level on all your devices, not just in the browser
• N1 Choose Quad9 (9.9.9.9) for security, or Mullvad/NextDNS depending on the need for privacy or visibility
• N1 Check for the absence of a DNS leak with dnsleaktest.com after every change
• N2 On iOS 14+: install the NextDNS or Cloudflare DNS profile (Settings > DNS Profile)
• N2 On Android 9+: enable Private DNS (DoT) in Settings > Network & Internet
• N2 Check that travel DNS holds at the system level, not just in the browser
• N2 At home: Pi-hole for filtering + Unbound for recursive resolution + encrypted upstream
• N3 In the enterprise: internal DNS resolver with logging (Umbrella, NextDNS Business, Infoblox) plugged into the SIEM
• N3 In the enterprise: disable wild application DoH via GPO/MDM, impose the controlled resolver as the single encryption point
• N3 Track the share of requests passing through the controlled resolver (> 98%) and the malicious-domain detection time

Going further

The normative references are in the frontmatter: RFC 8484 specifies DoH, RFC 7858 specifies DoT, and RFC 9460 describes the encryption of the SNI via ECH that completes the picture. On the resolver side, the privacy policies of Quad9 and NextDNS detail exactly what is logged — read them before entrusting your history to anyone.

DNS is only one piece of network hardening. To understand what a VPN really protects and what it doesn’t touch — including the trap of the out-of-tunnel DNS leak — see VPN: 95% of the marketing is false. For the uncontrolled networks where cleartext DNS is most exposed, read Public Wi-Fi: the real risk. And to apply this hardening at the operating-system level rather than application by application, see Hardening your OS.