Skip to content
WorakornKoonawootrittriron
Back to blog
Network security

What DNSSEC, DoH and DoT protect, and what's left for your logs

DNSSEC proves a DNS answer wasn't forged, DoT and DoH encrypt the hop to your resolver, and logs plus protective DNS help you spot DNS tunnels.

Intermediate10 min read

On this page
  1. Q: What can go wrong with plain DNS?
  2. Q: What does DNSSEC protect, and what does it not?
  3. Q: DoT vs DoH: what's encrypted, on which port, and why are security teams torn?
  4. Q: How do attackers use DNS as a channel?
  5. Q: What is protective DNS, and how does it help?
  6. Q: What should I log and alert on, at the resolver and at the firewall?
  7. The short version

Almost every connection starts with a DNS lookup, yet DNS is often the last thing a team thinks to monitor. Then there's the alphabet soup: DNSSEC, DoT, DoH, DoQ, protective DNS. People mix these up all the time, partly because they sound like they do the same job. They don't. Each one solves a different problem, and knowing which is which tells you what you're actually protected against.

This post is set out as the questions I find myself asking (and being asked) about DNS. Each answer links to the standard or guidance it comes from, so you can read further.

Q: What can go wrong with plain DNS?

Classic DNS was designed for a friendlier internet. A query normally goes over UDP or TCP to server port 53, unencrypted and unsigned. The only thing that ties a reply to its question is a 16-bit identifier chosen by whoever sent the query (plus the source port in practice). That design leaves four broad problems.

  • Spoofing and cache poisoning. If an attacker can guess the ID and port and get a forged reply in before the real one, a caching resolver may store the lie and serve it to everyone who asks after that. CERT/CC's 2008 note VU#800113 described how resolvers with weak transaction IDs or fixed source ports were exposed to exactly this. Randomising source ports adds roughly 16 more bits for an attacker to guess. In the vendor statement quoted in that note, ISC said that only DNSSEC fully counters this kind of attack.
  • Snooping. Anyone on the path can read the names you look up. That's a privacy problem for people and a reconnaissance gift for attackers.
  • Tampering on the path. A device in the middle can change answers. Sometimes that's done on purpose, for filtering. Sometimes it's an attacker.
  • Abuse as a channel. DNS is allowed out of nearly every network, so attackers use it to carry data. More on that below.

A useful way to keep these apart: poisoning and tampering are integrity problems, snooping is a confidentiality problem, and tunnelling is a detection problem. Each of the next answers covers one of them.

Q: What does DNSSEC protect, and what does it not?

DNSSEC adds signatures to DNS data. RFC 4033 says it gives three things: data origin authentication, data integrity, and authenticated denial of existence (proof that a name really doesn't exist). It adds four record types for this: RRSIG (signatures), DNSKEY (public keys), DS (a hash of a child zone's key, published in the parent zone) and NSEC (for signed "no such name" answers).

Trust builds as a chain. The resolver starts from a trust anchor it already holds, usually the root key. Each parent zone vouches for its child's key with a DS record, and each zone signs its own records. RFC 4033 writes the chain as DNSKEY -> [DS -> DNSKEY]* -> RRset.

A recursive lookup: the resolver walks root, TLD and authoritative servers, checks the RRSIG, then answers the stub.

The part that confuses people is what DNSSEC leaves out. RFC 4033 says it plainly: DNSSEC is not designed to provide confidentiality, and it provides no protection against denial of service. Every signed answer still crosses the network in clear text. NIST SP 800-81r3 (March 2026) agrees: DNSSEC protects integrity but "does not provide any confidentiality or privacy protection."

There's a second gap that matters inside an enterprise: the last hop. Most laptops run a non-validating stub resolver, and RFC 4033 notes that such a stub is at the mercy of its recursive resolver and of the link to it. The resolver can set the AD (Authenticated Data) bit to say "I validated this," but the stub can only trust that bit if it trusts both the resolver and the path. A stub that trusts neither can set the CD bit and check the signatures itself.

In one line: DNSSEC answers "is this the record the zone owner published?" It doesn't answer "who can see my query?"

Q: DoT vs DoH: what's encrypted, on which port, and why are security teams torn?

Both protect the hop between the client (stub) and the recursive resolver against eavesdropping and tampering. They differ in how they travel.

DNS over TLS (DoT) DNS over HTTPS (DoH) DNS over QUIC (DoQ)
Standard RFC 7858 RFC 8484 RFC 9250
Transport TLS over TCP HTTP over TLS (HTTP/2 is the minimum recommended version) QUIC over UDP
Default port TCP 853 443, like any HTTPS UDP 853
Looks like Its own service on its own port Ordinary web traffic Its own service on its own port

A few details from the RFCs are worth knowing:

  • DoT servers must listen on TCP 853 by default. Another port is allowed by mutual agreement, but RFC 7858 says it must not be port 53. The RFC covers stub-to-recursive traffic only, and it admits that message sizes and timing can still leak information to traffic analysis.
  • DoT's "opportunistic" profile gives privacy only when no active attacker is on the path. The stricter profile pins the server's key.
  • DoH sends a normal DNS message with the media type application/dns-message, either in a POST body or base64url-encoded in a GET parameter called dns (RFC 8484). The RFC names two goals: stopping on-path devices from interfering with DNS, and letting web applications use DNS safely through browser APIs.

So why the mixed feelings? Because the "on-path device" that DoH is designed to get around can be your own security stack. If a browser or app sends DoH straight to a public resolver over 443, the enterprise resolver never sees the query. Its filtering, logging and alerting are skipped without anyone noticing. NIST SP 800-81r3 addresses this head on: organisations may need to configure applications such as browsers "so that local resolvers that act as a point of control and logging are not bypassed."

The fix isn't to fight encryption. It's to own the encrypted endpoint: run (or subscribe to) a resolver that speaks DoT or DoH, point managed devices at it through policy, and block other resolvers at the edge. Firefox also checks a canary domain: it looks up use-application-dns.net through the operating system's resolver, and if the answer is an error such as NXDOMAIN or SERVFAIL, or has no A or AAAA records, Firefox treats that as a signal to turn off DoH. This only applies when DoH was enabled by default, not when the user turned it on (Mozilla). Treat that as a helpful signal, not a control. A user who switches DoH on by hand isn't affected by it.

Q: How do attackers use DNS as a channel?

MITRE ATT&CK tracks this as T1071.004, Application Layer Protocol: DNS. The idea is simple. The malware encodes data into the name it looks up, for example <encoded-chunk>.t.example. The query travels through your resolver as normal, all the way to the attacker's authoritative server for t.example. That server decodes the label and hides its reply in the answer, often in a TXT or A record.

Each query hides a few bytes in a long, random-looking label under one domain; the attacker&#39;s name server puts the message back together.

MITRE lists the reasons this works: DNS is very common, it may be allowed even before a device has authenticated to the network, its packets have plenty of fields and headers to hide data in, and the traffic blends in with normal lookups. The size limits from RFC 1035 (63 octets per label, 255 per name) mean each query carries only a small chunk. That's why tunnels show up as many queries, not a few large ones. ATT&CK's procedure examples include Cobalt Strike, which can wrap its C2 protocol in DNS, and SUNBURST, which used DNS for C2 made to look like SolarWinds API traffic.

The patterns MITRE's detection guidance points to are the ones in the animation:

  • long, encoded-looking subdomains;
  • a high volume of queries from one client;
  • DNS queries from processes that don't normally make them (scripts, interpreters);
  • queries to known-bad infrastructure.

The mitigations it lists are just as practical: filter DNS requests to unknown, untrusted or known-bad domains, and resolve DNS through your own on-premises or proxy servers, which MITRE notes may disrupt attempts to hide data in DNS packets (M1037), plus network IPS signatures for specific malware (M1031).

Q: What is protective DNS, and how does it help?

Protective DNS is a resolver that applies security policy to the lookups themselves. NIST SP 800-81r3 describes it as refusing to resolve names known for phishing or malware command and control, usually answering NXDOMAIN instead, and logging the attempt as a sign of possible infection. It's built from DNS firewalls or Response Policy Zones (RPZ) on your own servers, from a cloud secure-resolver service, or from both. NIST also says a good protective DNS service should analyse every record type, MX, SOA and TXT included, not just A records.

Where you run it changes what you see. NIST points out that RPZ servers placed close to clients make it easy to tell which device asked, while placing them close to the internet concentrates the deployment but loses some of that client visibility. Cloud services scale well but cost some confidentiality and make attribution harder.

The US government runs one at national scale. CISA's Protective DNS Resolver launched in 2022 as the successor to E3A. It addresses a congressional mandate for federal civilian executive branch agencies, and it's open to critical-infrastructure organisations on a limited basis through a pilot programme. When a query matches a threat-intelligence indicator, the service can block, redirect or sinkhole the response, and it alerts both the agency and CISA.

Protective DNS doesn't catch everything, though: it only sees queries that actually reach it. That's the DoH bypass problem again, and it's why the next answer matters.

Q: What should I log and alert on, at the resolver and at the firewall?

Start at the resolver, because it knows the names. NIST's guidance in SP 800-81r3 is concrete:

  • Keep current and historical DNS logs, and correlate them with other logs.
  • Logging everything is expensive, so use efficient formats (such as dnstap) or selective logging. But always log queries and responses for domains your protective DNS classifies as malicious.
  • You can remove entries for known secure domains (for example, zones your organisation runs and monitors elsewhere) before sending logs to the SIEM to save cost, but keep a complete log for forensics.
  • Keep DHCP lease history, so an IP address in a DNS log can be traced to a device at that time.
  • Send protective DNS logs to your SIEM or log platform so alerts arrive quickly.

On Windows Server, for example, the DNS analytic log isn't enabled by default. Once it is, event 257 records each successful response with fields such as the destination, QNAME, QTYPE, RCODE and the AD flag. Microsoft says the performance cost shows up only at high query rates: about 5% at 100,000 queries per second, and no apparent impact at 50,000 or below (Microsoft Learn).

At the firewall, the most useful thing is a policy that makes resolver logs complete:

At the edge, DNS is just another flow: allow it from your resolvers, drop and log it from everyone else.
  1. Allow outbound DNS (UDP/TCP 53), DoT (TCP 853) and DoQ (UDP 853) only from your resolvers. Drop and log it from everything else.
  2. Treat DoH to resolvers you don't operate as a policy question. Block well-known public DoH endpoints where your platform can identify them, and enforce your own resolver on managed devices.
  3. Alert on any internal host that talks DNS to the internet directly. Either it's misconfigured, or something is ignoring your resolver on purpose.

Then the alerts that tend to earn their keep:

  • a spike in NXDOMAIN answers from one host (randomly generated domains, or a broken app);
  • many unique subdomains under one parent domain, especially with long labels or TXT queries;
  • lookups of domains your protective DNS has flagged;
  • DNSSEC validation failures for zones you depend on (either an attack or a broken signature that will soon become an outage).

The short version

Problem What addresses it
Forged or poisoned answers DNSSEC validation (plus source port randomisation)
Someone reading your queries DoT, DoH or DoQ to a resolver you trust
Upstream servers seeing your full query name QNAME minimisation (RFC 9156)
Malware using DNS as a channel or a phone book Protective DNS, forced use of your resolvers, logging and detection

None of these replaces the others. DNSSEC without encryption still leaks, encryption without validation can still deliver a forged answer, and neither helps if your logs never see the query.

Sources

Keep reading

Related posts

Back to blog