DNS security

DNS was designed in the 1980s, when the internet was small and trusted. Its messages are plain UDP packets with no authentication. Anyone who can answer faster than the real server can forge a reply. Much of DNS security is about closing that gap, and about keeping queries from being read by networks in between.

The big idea

Three separate problems need three separate fixes:

1. Forged answers. An attacker injects a fake reply, so the resolver caches the wrong address. This is cache poisoning. DNSSEC fixes it by signing records.
2. Visible queries. Anyone on the path can read which names you look up. DoH and DoT fix it by encrypting the query.
3. Wrong destination even with a valid name. A correct DNS answer can still send a user to the wrong server if the certificate check is skipped. This is solved by TLS, not DNS.

Keeping these apart prevents a common mistake: thinking DNSSEC makes a connection safe. It only makes the name-to-address mapping verifiable.

Walking through it: DNSSEC

DNSSEC adds signatures to each zone's records. The zone's data is signed with a private key, and the public key is published in the zone as a DNSKEY record. Each parent zone signs a hash of its child's key, forming a chain of trust from the root down. The root's key is the trust anchor that resolvers ship with.

A validating resolver checks the signature on each answer. Here is a live answer for example.com with its RRSIG record, which carries the signature:

example.com.   200   IN   A       172.66.147.243
example.com.   200   IN   RRSIG   A 13 2 300 20261015160350 20261013140350 34505 example.com. XvEgvx...

The RRSIG line says the record is signed with algorithm 13 (ECDSA P-256 with SHA-256), that the signature expires on the date shown, and that it covers the A records. A validator checks that signature. A forged A record has no valid signature, so it is rejected.

DNSSEC does not encrypt anything, and it doesn't hide names. Its job is integrity. Its costs are real: larger responses that can push queries over UDP limits, key rollover is hard to get right, and a misconfigured signature makes the zone fail to resolve for validating resolvers. That last point is worth a runbook. A DNSSEC error looks like an outage.

Walking through it: DoH and DoT

DNS over TLS (DoT) runs DNS over a TLS connection on port 853. DNS over HTTPS (DoH) runs it over HTTPS on port 443, mixed in with normal web traffic. Both encrypt the query and the answer, so a network observer can't read the names, and can't easily tamper with the reply. The TLS handshake proves who the resolver is.

Encrypted DNS also moves queries away from network-level filters that some organizations rely on, so choose your fleet's resolvers deliberately.

Other protections

Resolvers randomize the query ID and source port, which makes a blind forgery harder. Keep authoritative and recursive roles on separate servers, because an open recursive resolver can be used to amplify attacks.

Common mistakes

• Believing DNSSEC encrypts queries or protects the connection. It signs answers only.
• Enabling DNSSEC and forgetting to monitor validation failures, which can cause a silent outage.
• Ignoring certificate validation because "DNS is secure now".

Check yourself

• Why does a forged DNS reply fail under DNSSEC? Answer: the record carries a signature from the zone's key, and the forged record has no valid signature for that chain of trust.
• Why do DoH and DoT help on a public Wi-Fi network? Answer: they encrypt the query, so the network can't read the names being looked up or change the answer on the way back.

Key takeaways

• DNSSEC signs records to stop forged answers. It does not encrypt queries.
• DoH and DoT encrypt queries between a client and its resolver.
• TLS certificate validation is still the final check that you reached the right server.

Further learning

Next, return to the DNS overview, or read TLS to see how the handshake proves the server's identity.