DNS Security: DNSSEC, DoH, and DoT Explained

The Domain Name System (DNS) translates human-readable names like example.com into IP addresses, but it was designed in an era that assumed a trusted network. DNS security addresses the resulting gaps: by default, lookups travel in plaintext and carry no proof of authenticity, letting attackers forge answers or observe what you resolve. Three complementary technologies, DNSSEC, DNS over HTTPS (DoH), and DNS over TLS (DoT), close different parts of this gap.

Why Plain DNS Is Vulnerable

A standard DNS query is a small UDP datagram sent to a resolver, which recursively queries authoritative servers and returns an answer. This design has two weaknesses:

• No authentication means a response is trusted if it merely matches the query's transaction ID and arrives on the expected port. An attacker who guesses or races these values can inject a forged answer, a technique known as cache poisoning.
• No confidentiality means that because queries are plaintext, anyone on the path can see every domain you look up and can tamper with responses.

These weaknesses enable redirection to malicious servers and surveillance of browsing behavior even when the destination site uses HTTPS.

DNSSEC Authenticating DNS Records

DNS Security Extensions (DNSSEC) add origin authentication and integrity to DNS data using public key cryptography. It does not encrypt anything; instead, it lets a resolver verify that records genuinely come from the zone's owner and were not altered in transit.

How the Chain of Trust Works

Each DNSSEC-signed zone publishes digital signatures (RRSIG records) over its record sets, along with public keys (DNSKEY records). Verification builds a chain:

1. A resolver fetches a record and its RRSIG signature.
2. It validates the signature using the zone's DNSKEY.
3. The parent zone publishes a Delegation Signer (DS) record that hashes the child's key, linking trust upward.
4. This continues to the root zone, whose key is a widely distributed trust anchor.

If any signature fails to validate, the resolver treats the data as bogus and withholds it. This defeats cache poisoning because a forged record cannot carry a valid signature.

What DNSSEC Does Not Do

DNSSEC authenticates data but does not hide it. Queries and answers remain visible on the wire. It also depends on correct deployment across the whole chain; a domain with no DS record in its parent cannot be validated. This is why DNSSEC pairs naturally with the encrypted transports below.

DNS over TLS and DNS over HTTPS

Where DNSSEC provides authenticity, DoT and DoH provide confidentiality by wrapping the query in an encrypted tunnel between the client and its resolver.

DoT DNS Inside a TLS Tunnel

DNS over TLS runs DNS messages inside a TLS connection, conventionally on port 853. The dedicated port makes DoT straightforward to identify on a network, which administrators may prefer for policy enforcement. The resolver presents a certificate the client validates, preventing an on-path attacker from impersonating it.

DoH DNS Inside HTTPS

DNS over HTTPS carries queries as HTTPS requests on port 443, blending DNS traffic with ordinary web traffic. Because it is difficult to distinguish from other HTTPS flows, DoH is harder for a network observer to single out or block, which benefits privacy but can complicate enterprise monitoring.

A quick way to issue a DoH query from the command line:

curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Both DoT and DoH protect the segment between client and resolver. They do not, by themselves, authenticate the DNS data end to end; that remains DNSSEC's job.

Choosing and Combining the Mechanisms

These technologies are complementary rather than competing:

• DNSSEC guarantees the answer is authentic and unaltered from the authoritative source.
• DoT and DoH guarantee the conversation with your resolver is private and tamper-resistant on the local path.

A strong posture uses encrypted transport to a trustworthy validating resolver that performs DNSSEC checks. That combination stops both eavesdropping on the local path and forged records injected anywhere along the resolution chain. Encrypted DNS also reduces the leakage that enables man-in-the-middle attacks that begin by hijacking name resolution.

Operational Considerations

Adopting these mechanisms involves trade-offs worth planning for:

• Centralizing lookups at one DoH or DoT provider shifts visibility and trust to that operator, so the resolver choice matters.
• Encrypted DNS can bypass internal filtering that relies on inspecting plaintext queries, which security teams must account for.
• DNSSEC validation adds cryptographic work and requires zone operators to manage key rollovers carefully to avoid outages.

Key Takeaways

• Plain DNS lacks both authentication and encryption, enabling cache poisoning and surveillance of lookups.
• DNSSEC signs records so resolvers can verify authenticity and integrity through a chain of trust anchored at the root.
• DNSSEC does not encrypt; DoH and DoT add confidentiality by tunneling queries to the resolver.
• DoT uses a dedicated port that is simple to manage, while DoH hides queries within normal HTTPS traffic.
• The strongest approach combines encrypted transport with a DNSSEC-validating resolver you trust.