DNS Privacy: DoH, DoT, and DNSSEC Compared

Why DNS Privacy Matters

Every time you visit a website, send an email, or connect to any internet service, your device performs a DNS query to translate the human-readable domain name into an IP address. These DNS queries have traditionally been sent in plaintext over UDP port 53, visible to anyone who can observe the network traffic -- your ISP, network administrators, public Wi-Fi operators, and anyone performing a man-in-the-middle attack.

The privacy implications are significant. DNS queries create a complete record of every internet service a user or organization interacts with. An ISP can see that you visited a healthcare provider's patient portal, a specific news outlet, a job search platform, or a competitor's website. This metadata reveals patterns of behavior that many users and organizations consider private.

Beyond privacy, plaintext DNS is vulnerable to manipulation. DNS spoofing attacks can redirect queries to malicious servers, sending users to phishing sites or injecting malware into software updates. DNS cache poisoning can affect entire networks by corrupting resolver caches with fraudulent records. For a broader look at what your DNS configuration exposes to attackers, see DNS Security: What Your Domain Configuration Reveals.

Three technologies address these concerns, each targeting different aspects of DNS security and privacy: DNSSEC ensures DNS responses have not been tampered with, DNS over TLS (DoT) encrypts DNS queries in transit, and DNS over HTTPS (DoH) both encrypts queries and makes them indistinguishable from regular web traffic.

DNSSEC: Authentication Without Encryption

DNSSEC (Domain Name System Security Extensions) was the first major effort to secure DNS, standardized through RFC 4033-4035. DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses came from the authoritative source and were not modified in transit.

How DNSSEC Works

Each DNS zone signs its records with a private key. The corresponding public key is published in the zone as a DNSKEY record. When a resolver queries a DNSSEC-enabled domain, it receives both the requested record and a digital signature (RRSIG record). The resolver validates the signature using the published public key, verifying authenticity and integrity.

Trust is established through a chain of signatures from the root zone down through each level of the DNS hierarchy. The root zone signs .com, .com signs example.com, and example.com signs its individual records. A resolver that trusts the root zone's public key can validate any record in the chain.

What DNSSEC Protects Against

• DNS spoofing: An attacker cannot forge DNS responses because they do not have the zone's private signing key
• Cache poisoning: Corrupted records fail signature validation and are rejected
• Man-in-the-middle modification: Any alteration to a DNS response invalidates the signature

What DNSSEC Does Not Protect Against

• Query privacy: DNSSEC does not encrypt anything. Queries and responses remain visible in plaintext. An observer can still see which domains you are querying.
• Query eavesdropping: ISPs and network operators can still log all DNS queries
• Denial of service: DNSSEC adds complexity that can be exploited for amplification attacks

DNSSEC Configuration

DNSSEC is configured at the domain level, not the client level. Domain owners enable DNSSEC through their DNS hosting provider and registrar:

1. The DNS host generates signing keys and signs the zone
2. The DS (Delegation Signer) record is published at the registrar
3. The registrar publishes the DS record in the parent zone

Verification:

# Check if a domain has DNSSEC
dig +dnssec example.com A

# Look for RRSIG records in the response
# and the 'ad' (authenticated data) flag

CyberShield's DNS module checks whether DNSSEC is enabled and properly configured for your domains, flagging domains that lack DNSSEC protection. If you need help enabling DNSSEC, our DNSSEC and CAA records setup guide walks through the full process from key generation to DS record publication.

DNS over TLS (DoT): Encrypted DNS Queries

DNS over TLS (DoT), standardized in RFC 7858, encrypts DNS queries by wrapping them in a TLS connection. It operates on a dedicated port (TCP 853) and provides confidentiality for DNS traffic between the client (stub resolver) and the recursive resolver.

How DoT Works

Instead of sending DNS queries in plaintext over UDP port 53, the client establishes a TLS connection to the resolver on port 853. All DNS queries and responses within that session are encrypted, preventing eavesdropping.

The TLS connection provides:

• Confidentiality: Query content is encrypted, so observers cannot see which domains are being resolved
• Integrity: TLS prevents modification of queries and responses in transit
• Authentication: The client can verify the resolver's identity through its TLS certificate

DoT Advantages

• Clear separation: Uses a dedicated port (853), making it easy to identify and manage at the network level
• Network visibility: Network administrators can detect and monitor DoT usage through port-based traffic analysis
• Policy enforcement: Organizations can block or redirect port 853 to enforce use of approved resolvers

DoT Limitations

• Easily blocked: Because DoT uses a dedicated port, it is trivially blocked by firewalls, ISPs, or governments that want to prevent encrypted DNS
• Traffic analysis: Even though query content is encrypted, an observer can see that DNS queries are being sent (because port 853 is exclusively used for DoT)
• Client support: Requires operating system or application-level configuration

DoT Configuration

On Linux systems with systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes

On Android (9+): Settings > Network > Private DNS > Set to dns.google or one.one.one.one

DNS over HTTPS (DoH): DNS as Web Traffic

DNS over HTTPS (DoH), standardized in RFC 8484, sends DNS queries as HTTPS requests to a web server. It operates on port 443, the same port used by all HTTPS web traffic, making DNS queries indistinguishable from regular web browsing.

How DoH Works

The client sends DNS queries as HTTP requests (using GET or POST methods) to a DoH resolver endpoint (e.g., https://cloudflare-dns.com/dns-query). The DNS query is encoded in the HTTP request body or URL parameters, and the response is returned as an HTTP response. The entire exchange occurs within a standard HTTPS connection.

DoH Advantages

• Censorship resistance: Because DoH uses port 443 (standard HTTPS), blocking it requires blocking all HTTPS traffic or performing deep packet inspection. This makes DoH significantly harder to block than DoT.
• Traffic blending: DNS queries are indistinguishable from regular web traffic to a network observer, providing stronger privacy against passive surveillance.
• Browser integration: Major browsers (Chrome, Firefox, Edge, Safari) have built-in DoH support, providing encrypted DNS without requiring OS-level configuration.

DoH Limitations

• Reduced network visibility: Organizations cannot easily distinguish DoH traffic from regular HTTPS traffic, making it harder to monitor and enforce DNS policies. This is both a privacy feature and a management challenge.
• Centralization concerns: Browser DoH implementations default to specific resolvers (Google, Cloudflare), potentially centralizing DNS resolution with a few large providers.
• Bypass risk: Users can enable DoH in their browser to bypass organizational DNS filtering and security policies, which may conflict with enterprise security requirements.

DoH Configuration

In Firefox: Settings > Privacy & Security > DNS over HTTPS > Select provider

In Chrome: Settings > Privacy and Security > Security > Use secure DNS

At the OS level (Windows 11):

# Add DoH server
netsh dns add encryption server=1.1.1.1 dohtemplate=https://cloudflare-dns.com/dns-query
# Enable DoH
Set-DnsClientDohServerAddress -ServerAddress "1.1.1.1" -DohTemplate "https://cloudflare-dns.com/dns-query" -AllowFallbackToUdp $false -AutoUpgrade $true

Comparison: DNSSEC vs DoT vs DoH

Feature	DNSSEC	DoT	DoH
Protects	Response authenticity	Query privacy	Query privacy + censorship resistance
Encrypts queries	No	Yes	Yes
Validates responses	Yes	No (by itself)	No (by itself)
Port	53 (same as standard DNS)	853 (dedicated)	443 (shared with HTTPS)
Configured by	Domain owner	Client/resolver	Client/resolver/browser
Blockable	Not applicable	Yes (block port 853)	Difficult (requires DPI)
Network visibility	Full	Detectable by port	Blends with web traffic
Prevents spoofing	Yes	Against network observers	Against network observers
Prevents eavesdropping	No	Yes	Yes

The critical insight is that these technologies are complementary, not competing:

• DNSSEC ensures the DNS data itself is authentic (the domain owner signed it)
• DoT/DoH ensures the query and response are private (nobody can see what you asked)
• DNSSEC + DoT/DoH provides both authentication and privacy

Without DNSSEC, DoT and DoH protect against eavesdropping but not against a compromised resolver returning forged data. Without DoT or DoH, DNSSEC prevents tampering but does not prevent observation of what you are querying.

Implications for External Security

From a domain owner's perspective, DNSSEC is the actionable technology. You cannot control whether your users use DoT or DoH (that is a client-side decision), but you can enable DNSSEC on your domains to protect your DNS responses from tampering regardless of how clients resolve them.

What Domain Owners Should Do

Enable DNSSEC on all domains. This protects your visitors from DNS spoofing attacks that could redirect them to phishing sites impersonating your services. CyberShield's DNS module checks DNSSEC configuration and flags domains without it.

Publish CAA records to restrict certificate issuance. CAA records complement DNSSEC by declaring which CAs can issue certificates for your domain:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Configure proper NS records with multiple nameservers on diverse networks for resilience.

Monitor DNS configuration through regular scanning to detect unauthorized changes, dangling records, and configuration drift.

What Organizations Should Consider

For enterprise networks: Evaluate deploying internal DoH or DoT resolvers that provide encrypted DNS while maintaining organizational visibility and filtering capabilities. This gives employees privacy from external observers while preserving the organization's ability to enforce security policies.

For compliance: DNSSEC may be relevant to compliance requirements. NIST 800-53 recommends DNSSEC, and frameworks like PCI-DSS and HIPAA that require data integrity protection can consider DNSSEC as a supporting control for DNS-dependent communications.

For monitoring: Understand that DoH adoption among browsers means you may have reduced visibility into DNS queries from endpoint devices. Adjust monitoring strategies accordingly -- endpoint-level DNS monitoring may need to supplement network-level monitoring.

What CyberShield Checks

CyberShield's DNS module evaluates the domain owner's side of DNS security:

• DNSSEC: Whether DNSSEC is enabled and properly validated for your domains
• CAA records: Whether certificate authority restrictions are published
• NS configuration: Whether nameservers are properly configured with redundancy
• Zone transfer: Whether zone transfers are restricted to authorized servers
• DNS record health: SOA configuration, consistency checks, and record hygiene

These checks ensure that regardless of whether users access your domain through traditional DNS, DoT, or DoH, the DNS data they receive is authentic and your domain infrastructure is properly secured. The client-side privacy choice (DoT vs DoH vs plaintext) is the user's decision. The server-side integrity guarantee (DNSSEC) is yours.