DNS Security: DoH and DoT

The Domain Name System translates human-readable domain names into IP addresses. Standard DNS queries use UDP on port 53 and are sent completely unencrypted. Every domain name your device looks up is visible to your router, your ISP, and anyone capable of monitoring the network path. This means your browsing activity is exposed even when every website you visit uses HTTPS.

Internet Service Providers routinely log DNS queries for all customers as a form of network monitoring and for compliance with data retention laws in many jurisdictions. This log constitutes a detailed record of every website visited, the time of each visit, and the frequency of access. ISPs have sold this data to advertisers and responded to government requests for subscriber browsing histories based on DNS logs alone.

An attacker who can intercept or redirect DNS traffic can manipulate the responses to point users to malicious servers. DNS hijacking can occur at the router level (if the router is compromised), through rogue DHCP servers that provide attacker-controlled DNS resolver addresses, or through ISP-level redirection. Users who type a legitimate domain name can be silently directed to a phishing site with no indication of the redirect.

When a device joins a network it requests configuration via DHCP, which provides an IP address, gateway, and DNS server. An attacker on the local network who runs a rogue DHCP server can respond faster than the legitimate server and provide their own DNS server address. All subsequent DNS queries from the victim go to the attacker's resolver, enabling query surveillance and response manipulation throughout the session.

In 2008, researcher Dan Kaminsky disclosed a critical vulnerability in DNS. By sending thousands of forged DNS responses with random transaction IDs, an attacker could statistically corrupt the cache of a resolver before it received the legitimate response. This is known as birthday-attack-style cache poisoning. A corrupted cache redirects all users of that resolver to attacker-controlled IP addresses for the poisoned domain.

DNSSEC (DNS Security Extensions) addresses cache poisoning and response forgery by adding cryptographic signatures to DNS records. Each DNS zone signs its records with a private key; resolvers verify signatures using the corresponding public key published in DNSKEY records. A forged or modified response will fail signature verification and be rejected. DNSSEC creates a chain of trust from the DNS root zone down to individual domain records.

DNS-over-TLS (DoT) wraps DNS queries inside a standard TLS connection on port 853. The resolver and client perform a TLS handshake before any DNS queries are sent, encrypting both the query (including the domain name) and the response. DoT prevents passive surveillance by ISPs and network observers. The use of a dedicated port (853) makes it identifiable by firewalls, which some networks use to block DoT.

DNS-over-HTTPS (DoH) encodes DNS queries as HTTPS requests on port 443, the same port used for all web traffic. Because DoH traffic is indistinguishable from regular HTTPS, it cannot be easily blocked by firewalls without also blocking all HTTPS traffic. DoH is supported natively in Firefox, Chrome, and Windows 11, with providers including Cloudflare (1.1.1.1) and Google (8.8.8.8) offering DoH endpoints.

With DoH or DoT, your DNS queries are encrypted in transit between your device and the DNS resolver. Your ISP cannot read or log the individual domain names you query. Rogue DHCP attacks cannot inject a resolver that reads your traffic because the legitimate resolver is hardcoded. Network attackers cannot perform DNS hijacking through passive interception. However, the DNS resolver itself still sees all your queries.

ISPs have lobbied against mandatory DoH deployment because it shifts DNS visibility from ISPs to a small number of large tech company resolvers. UK ISPs complained to Parliament that DoH would prevent parental control filtering. Network administrators argue that centralised DoH breaks enterprise DNS policies and split-horizon DNS configurations. The IETF standardised DoH in RFC 8484 but deployment policy remains contested.

DNSSEC requires both the domain owner to sign their zone and the resolver to perform validation. Key rollover (changing signing keys without service disruption) is complex and has caused outages for major TLDs. Misconfigured DNSSEC can make a domain completely unreachable. The .com and .net TLDs support DNSSEC, but only a minority of individual domains are signed. DNSSEC does not encrypt queries; only DoH and DoT provide query privacy.

Why is DoH preferred over DoT in environments where restrictive firewalls block non-standard ports?

Standard DNS on UDP port 53 is unencrypted and logged by ISPs. DNS hijacking and Kaminsky cache poisoning attacks exploit this weakness. DNSSEC adds cryptographic signatures to prevent response forgery but does not encrypt queries. DoT on port 853 and DoH on port 443 encrypt DNS queries in transit. DoH is harder to block than DoT. Encrypted DNS shifts trust from ISPs to resolver operators but does not eliminate trust requirements.