DNS Security and Privacy

• DNS Security and Privacy
  • The most trusted, least protected protocol
  • The threat: why plaintext DNS is dangerous
  • Integrity: DNSSEC (in brief)
  • Confidentiality: encrypted DNS transports
    • The remaining privacy gap → Oblivious DoH
  • Worked example: querying DNS three ways
  • Putting it together: defense in depth for DNS
  • Key takeaways
  • References

The most trusted, least protected protocol

Every connection you make starts with a DNS lookup. Before your browser can reach pdx.edu, it asks a resolver “what is the IP address for pdx.edu?” — and then it trusts the answer completely. That makes DNS one of the highest-value targets on the Internet, and for most of its history it has been one of the least protected.

Classic DNS (1987) runs over UDP port 53 in plaintext, with no encryption and no authentication. Two consequences follow directly, and — exactly as with email security — they are different problems with different fixes:

1. No authenticity / integrity — you cannot tell whether an answer is genuine or forged. An attacker who can inject a response can send you to their server instead (DNS spoofing / cache poisoning). The fix is DNSSEC.
2. No confidentiality — anyone on the path (your ISP, the coffee-shop Wi-Fi, a government) can read every domain you look up, building a complete profile of your browsing, and can block or tamper with answers for censorship. The fix is encrypted DNS transports (DoT, DoH, ODoH).

DNSSEC and encrypted transports are orthogonal — you can have either, both, or neither. DNSSEC proves an answer is real but sends it in the clear; DoT/DoH hide the query but do not, by themselves, prove the answer is authentic. This page focuses on the confidentiality side (the network-security page covers DNSSEC in depth), because that is the part the Week 6 schedule calls out and the part with no other coverage.

The threat: why plaintext DNS is dangerous

  You ──"A? pdx.edu"──▶ Resolver ──▶ ... ──▶ Authoritative server
        UDP/53 cleartext
         ▲
         │  Anyone on this path can:
         ├─ READ it  → know every site you visit (surveillance, ad-profiling)
         ├─ FORGE a reply → cache poisoning, send you to a malicious IP
         └─ DROP/REWRITE it → censorship, captive portals, ISP "helpful" redirects

• Cache poisoning — the Kaminsky attack (2008) showed an off-path attacker could flood a resolver with forged responses (guessing the 16-bit query ID) and poison its cache, redirecting an entire ISP’s users. Source-port randomization mitigated it; DNSSEC fixes it cryptographically.
• Surveillance — because lookups are cleartext, your DNS history is a near-perfect record of your activity. ISPs have monetized it; networks log it.
• Manipulation / censorship — many national firewalls and content filters work primarily by tampering with DNS, returning false answers for blocked domains.

Integrity: DNSSEC (in brief)

DNSSEC (DNS Security Extensions) adds digital signatures (the cryptography primitive) to DNS records. Each zone signs its records, and a chain of trust runs from the root zone down, so a validating resolver can prove an answer genuinely came from the domain owner and was not altered. This is what stops cache poisoning, and it is the foundation that DANE builds on to pin TLS certificates in DNS.

⚠️ DNSSEC authenticates; it does not encrypt. A DNSSEC-signed answer is still sent in plaintext — anyone on the path still sees which domain you asked about. For privacy you need an encrypted transport, below.

Confidentiality: encrypted DNS transports

These wrap the query/response in encryption so on-path observers cannot read or tamper with it. They differ mainly in what they tunnel through and how hard they are to block.

• DoT (DNS over TLS) wraps DNS in a TLS connection on port 853. Clean and simple, but because it has its own port, a network operator can see “this is encrypted DNS” and block it outright (forcing fallback to plaintext).
• DoH (DNS over HTTPS) sends DNS queries as HTTPS requests on port 443, so they blend into the ocean of ordinary web traffic. This makes DoH much harder to censor — you cannot block it without blocking HTTPS — which is exactly why it is simultaneously praised (privacy/censorship-resistance) and criticized (it bypasses enterprise DNS filtering and network visibility). That tension is a genuine, ongoing policy debate, not a settled question.

The remaining privacy gap → Oblivious DoH

DoT and DoH hide your queries from the network, but the resolver itself still sees both your IP address and every domain you ask for — you have simply moved the trust from your ISP to whoever runs the resolver (often a large provider like Cloudflare or Google).

Oblivious DoH (ODoH, RFC 9230) closes that gap with privacy partitioning: it inserts a proxy between you and the resolver, and encrypts the query to the resolver so the proxy cannot read it. The result:

• the proxy sees your IP but not your query (it is encrypted to the target);
• the resolver/target sees the query but not your IP (it came from the proxy).

No single party knows both who you are and what you asked — as long as the proxy and target do not collude. This is the same decoupling idea behind Tor and Apple’s iCloud Private Relay.

Worked example: querying DNS three ways

Plain dig (over UDP/53) shows the cleartext baseline:

$ dig +short pdx.edu
131.252.115.86          # this query and answer were visible to everyone on-path

To make the query encrypted, use kdig (from the knot-dnsutils package; modern dig 9.18+ also supports +tls/+https). DNS over TLS to Cloudflare on port 853:

$ kdig -d @1.1.1.1 +tls pdx.edu
;; DEBUG: TLS, handshake completed, ... TLS 1.3
;; TLS session is established.                 ← the lookup is now encrypted
pdx.edu.   3600   IN   A   131.252.115.86

DNS over HTTPS to the same provider (note it rides ordinary https://):

$ kdig -d @https://cloudflare-dns.com/dns-query +https pdx.edu
;; DEBUG: HTTP status: 200
pdx.edu.   3600   IN   A   131.252.115.86

On a systemd-based Linux box you can see and set the system resolver’s encryption mode:

$ resolvectl status | grep -i 'DNS over\|Current DNS'
  +DNSOverTLS=opportunistic                     # is DoT enabled?
$ resolvectl query pdx.edu                      # uses the configured transport

To confirm DNSSEC validation specifically, the ad (Authenticated Data) flag in a response means the resolver validated the signatures:

$ dig +dnssec +short pdx.edu             # request DNSSEC records
$ dig pdx.edu | grep -o 'flags:[^;]*'    # look for the 'ad' flag
flags: qr rd ra ad                       # 'ad' = answer was DNSSEC-validated

Putting it together: defense in depth for DNS

No single mechanism gives you a secure and private lookup:

The fully-protected lookup combines a DNSSEC-validating resolver reached over an encrypted (and ideally oblivious) transport — integrity and confidentiality, the same dual goal you saw in email security.

Key takeaways

• Classic DNS is plaintext UDP/53 with no authentication — you trust the answer completely, which makes it a prime target for spoofing/cache poisoning and a goldmine for surveillance and censorship.
• Integrity and confidentiality are separate problems: DNSSEC signs answers (authenticity) but does not encrypt them; DoT/DoH encrypt the query but do not by themselves prove authenticity.
• DoT (port 853) is easy to spot and block; DoH (port 443) hides among web traffic and is censorship-resistant — which also makes it controversial for enterprise visibility.
• Even with DoT/DoH the resolver still sees your IP and your queries; Oblivious DoH uses a proxy so no single party knows both.
• Verify it yourself: kdig +tls / +https for encrypted transport, and the ad flag for DNSSEC validation.

References

• RFC 4033/4034/4035 — DNS Security Extensions (DNSSEC). https://datatracker.ietf.org/doc/html/rfc4033
• RFC 7858 — DNS over TLS (DoT). https://datatracker.ietf.org/doc/html/rfc7858
• RFC 8484 — DNS over HTTPS (DoH). https://datatracker.ietf.org/doc/html/rfc8484
• RFC 9250 — DNS over Dedicated QUIC Connections (DoQ). https://datatracker.ietf.org/doc/html/rfc9250
• RFC 9230 — Oblivious DNS over HTTPS (ODoH). https://datatracker.ietf.org/doc/html/rfc9230
• D. Kaminsky, Black Ops 2008: It’s the End of the Cache As We Know It — the cache-poisoning attack. https://www.blackhat.com/presentations/bh-dc-09/Kaminsky/BlackHat-DC-09-Kaminsky-DNS-Critical-Infrastructure.pdf
• kdig(1) — Knot DNS diagnostic tool (DoT/DoH support). https://www.knot-dns.cz/docs/latest/html/man_kdig.html
• Cloudflare, DNS over TLS vs. DNS over HTTPS. https://www.cloudflare.com/learning/dns/dns-over-tls/

Related course pages: Introduction to Networking · Network Security · Email Security · Cryptography · VPNs and IPSec

🛠️ Maintenance note: DoQ (RFC 9250) and ODoH (RFC 9230) are relatively recent and client support is still maturing — re-verify kdig/resolvectl flag support against the course VM each term. The DoH-vs-enterprise-visibility debate and browser defaults (Firefox/Chrome auto-DoH rollout) continue to shift; refresh that framing yearly.