DNS Security: DNSSEC, DoH and the Exfiltration Channel

DNS is the internet's phone book, and almost no one looks at it. Every connection begins with a name lookup, those lookups are usually permitted to leave a network unfiltered, and for decades they travelled in plaintext with no way to tell a real answer from a forged one. That combination — trusted, universal, and historically unauthenticated — makes DNS both a target to be poisoned and a channel to be abused. Understanding DNS security means holding three separate problems in mind at once.

The first problem is integrity: can you trust the answer? Classic DNS has no authentication, so a well-positioned attacker can forge or poison a response and send a victim to a server they control while the address bar looks correct. The second is confidentiality: who can see your lookups? Plaintext DNS lets anyone on the path read exactly which sites you visit. The third — the one defenders underrate — is exfiltration: DNS as a covert tunnel out of a network that blocks everything else.

DNSSEC and DoH solve different halves

DNSSEC addresses integrity. It signs DNS records so a resolver can cryptographically verify that an answer really came from the zone's owner and was not tampered with in transit — it does not hide the query, it authenticates the response. DoH and DoT (DNS over HTTPS/TLS) address confidentiality by encrypting the query so on-path observers cannot read or trivially tamper with it. They are complementary, not competing: one proves the answer is genuine, the other keeps the question private. Conflating them is the most common DNS-security confusion.

DNS as the exfiltration channel

Because DNS is allowed to leave almost every network, attackers encode stolen data into the names they look up. A query for a long, random-looking subdomain of an attacker-controlled zone carries data outward; the attacker's authoritative server reads it and can answer back. It is slow and clumsy, and it works precisely because DNS is the one protocol egress filtering forgets. Malware has used this for command-and-control and for quietly draining data past firewalls that block every other outbound path.

• Enable DNSSEC validation on your resolvers, and sign your own zones. Validation rejects forged answers; signing lets others verify yours. Together they close the poisoning window.
• Have a deliberate DoH policy, don't leave it to chance. Decide whether clients and browsers use your controlled encrypted resolver — uncontrolled DoH to a third party bypasses your DNS security entirely.
• Route DNS through resolvers you monitor. Centralise resolution so you can still see and analyse queries; block direct DNS to arbitrary external resolvers.
• Watch for tunnelling signatures. Abnormally long subdomains, high query volume to a single domain, and high-entropy names are the classic tells of DNS exfiltration.
• Apply DNS filtering. Blocking resolution of known-malicious and newly-registered domains stops a large fraction of malware before the first connection is even made.

The unglamorous truth

DNS security rarely gets budget because DNS 'just works', and that is exactly why it is worth attention. It is a control plane that touches every connection, an intelligence source that reveals intent before payload, and an egress path most networks leave wide open. Treat your resolvers as security infrastructure: validated, encrypted on your terms, monitored, and filtered. The organisation that cannot see its own DNS queries has surrendered its earliest and cheapest signal.

You cannot secure or monitor DNS you do not control — and rogue resolvers and unmanaged devices are the ones that route around you. DNS security begins by discovering every resolution path in your estate, because you can't watch what you haven't discovered.