DNS Security & Privacy

6 min read•Published Sep 2, 2025

Overview of DNSSEC for integrity and DoH/DoT for encrypted, private DNS queries.

Threats and protections

  • Integrity: DNSSEC signs records to prevent tampering and cache poisoning.
  • Confidentiality: DoH/DoT encrypt queries between you and the resolver.
  • Privacy: Resolver policies affect logging, retention, and sharing.

In one line

DNSSEC proves the answer is legit. DoH/DoT hide your question in transit.Policies decide what happens to your data after that.

DNSSEC basics

DNSSEC adds a chain of trust using public-key cryptography. Resolvers validate signatures from the root through TLD to the zone, detecting tampered answers. It doesn’t encrypt traffic—just verifies authenticity.

How validation works

1

The zone publishes DNSKEY (public keys) and signs records, creating RRSIG signatures.

2

The parent zone publishes a DS record that references the child zone’s key (delegation).

3

A validating resolver walks the chain: Root → TLD → zone, checking DS↔DNSKEY and RRSIG.

4

If anything breaks (missing DS, bad signature, expired key), the answer is marked bogus.

What DNSSEC catches

  • Cache poisoning attempts (forged answers)
  • Tampered records on path or at a compromised resolver
  • Non-existent domains via NSEC/NSEC3 proofs (no wildcard trickery)

Note: DNSSEC doesn’t hide content; use DoH/DoT for confidentiality.

Encrypted DNS: DoH and DoT

  • DoT runs DNS over TLS (port 853). Simpler to filter/firewall; explicit DNS channel.
  • DoH runs DNS over HTTPS (port 443). Blends with web traffic; harder to block selectively.

When to prefer DoT

  • Clear network policy separation (dedicated DNS port)
  • Simpler enterprise controls and monitoring
  • Gateway-level deployments on routers/firewalls

When to prefer DoH

  • Works in restrictive networks (rides on 443)
  • Per‑app policies in browsers and OS features
  • Roaming devices that leave corporate perimeter

Performance is typically comparable to standard DNS if the resolver is nearby and supports HTTP/2 or QUIC. The bigger wins are confidentiality and policy control—not raw speed.

Resolver policies

Public resolvers differ on logging, retention, and filtering. Review provider policies to choose between security features (malware blocking, parental controls) and strict privacy (minimal logs, jurisdiction choices).

Questions to ask

  • Do you validate DNSSEC by default?
  • What logs are kept, and for how long?
  • Which country’s laws apply to the service and stored data?
  • Are security filters optional and well‑documented?
  • Do you support both DoH and DoT endpoints?

Best practices

  • Use a resolver that supports DNSSEC validation and enable it on authoritative zones where possible.
  • Prefer encrypted DNS (DoH/DoT) on clients and networks you control.
  • Audit resolver policies (logs, jurisdiction, data sharing) for your threat model.
  • Monitor for spoofing/poisoning indicators and cache anomalies.

Quick recommendations

  • Home users: Use a reputable public resolver with DoH/DoT enabled in your browser/OS.
  • Power users: Run a local validating resolver (e.g., on your router) and forward over DoT.
  • Admins: Standardize on DoT internally; allow DoH per‑app where needed, document exceptions.

Key takeaways

  • DNSSEC = authenticity, not confidentiality.
  • DoH/DoT protect queries on the wire; choose based on deployment constraints.
  • Provider policy matters for real privacy outcomes.

New to DNS? Start with What is DNS? and DNS Record Types.

Table of Contents