DNS Security: Resolution, Poisoning, DNSSEC and Encrypted DNS

TL;DR: A query goes from the stub to a recursive resolver, which walks root, TLD and authoritative servers and caches the result. Attackers forge answers into caches, run or compromise resolvers, take over the domain at the registrar or DNS provider, or claim resources behind dangling records. DNSSEC lets a validating resolver detect forged records; it encrypts nothing. DoH/DoT encrypt the hop to the resolver; they prove nothing about the record's origin. TLS validation catches a wrong address for HTTPS sites either way.

Before you read

Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.

1. 1A company enables DNS over HTTPS on all laptops to a public resolver. Does this protect against cache poisoning of that resolver?

   Commit to a guess, then reveal

How resolution works

1. The application asks the operating system's stub resolver.
2. The stub asks a configured recursive resolver (corporate, ISP or public).
3. On a cache miss, the recursive resolver asks a root server where the TLD's servers are, asks the TLD's servers where the domain's authoritative servers are, and asks those for the record.
4. Each answer is cached for its TTL.

Classic DNS commonly uses UDP on port 53, with TCP also required. For UDP, a resolver matches the question, transaction ID, source and destination addresses, and source and destination ports against an outstanding query. These checks establish a matching response, not cryptographic authenticity; record-admission rules and DNSSEC validation also matter.

Three details of that flow carry most of the security weight:

• Delegation is just more DNS. The TLD tells the resolver "example.com is served by these name servers" with NS records, and often supplies their addresses as "glue". Whoever can change those NS records at the registry controls the whole domain. That is why the registrar account is the crown jewel.
• Caching multiplies both performance and damage. One poisoned answer with a 24-hour TTL is served to every client of that resolver for a day without any further attacker effort.
• The stub trusts the recursive resolver completely. Almost no stub validates DNSSEC itself. Whatever resolver DHCP, the VPN or the browser picks is, in practice, the source of truth for every name on that device.

Where it is attacked

• Cache poisoning. Forged responses accepted into a resolver's cache affect every client of that resolver for the TTL. Dan Kaminsky's 2008 technique made repeated attempts practical by querying random subdomains and injecting authority records; resolvers responded with source port randomisation, multiplying the guess space.
• Malicious resolver. On hostile networks, DHCP hands out an attacker's resolver.
• Domain takeover. Compromised registrar or DNS hosting accounts change records at the source.
• Dangling records. A CNAME to a deleted cloud resource creates a takeover risk if another party can claim the target under that provider's ownership and verification rules.

Cache poisoning in detail

A recursive resolver sends a query and waits. A forged UDP response must pass the outstanding-query matching and record-admission checks to enter the cache. An off-path attacker attempts to guess the required values before the legitimate answer arrives. A matching packet still cannot forge a valid DNSSEC signature for a securely signed zone.

Before 2008, the attacker had one shot per name per TTL: once the real answer was cached, no new query went out. Kaminsky's insight was to ask about names that cannot be cached because they do not exist yet (random123.bank.example, then random124.bank.example) and to put the payload in the authority section of the forged answer: "and by the way, the name server for bank.example is at this address". Each random name is a fresh race, so the attacker gets as many attempts as they can send queries. Resolvers that accepted that out-of-band authority data handed over the whole domain.

The fixes stacked entropy and scepticism:

• Source port randomisation multiplies the 65,536 transaction IDs by tens of thousands of ports. The attacker positions lesson works the numbers: from a 78% chance after 1,000 races to about 0.005%.
• 0x20 encoding randomises the letter case of the query name (wWw.BaNk.eXaMpLe) and requires the answer to echo it exactly, adding a bit of entropy per letter.
• Bailiwick checking makes resolvers ignore authority and additional records for names outside the zone being asked about.
• DNSSEC ends the guessing game: a forged record does not carry a valid signature, however well it is timed.

Side channels keep reopening the gap. The 2020 SAD DNS research inferred a resolver's ephemeral source port from the shared ICMP rate limit, which collapses the port's entropy back to a scan. Patches made the limit randomised, but the lesson is structural: randomisation is a secret that the attacker may find a way to read, and only signatures do not depend on secrecy.

DNSSEC: a chain of signatures

DNSSEC works as a chain: each zone's key is vouched for by its parent through a DS record, up to the root's trust anchor. Deployment is uneven, and signing adds operational risk (expired signatures make a domain unresolvable for validating resolvers).

The record types worth naming in an interview:

Algorithms age too. RFC 9905 (December 2025) deprecates SHA-1-based DNSSEC signature algorithms, and current guidance favours ECDSA P-256 (algorithm 13) or Ed25519 (algorithm 15), whose small signatures also keep responses under the size that forces fallback to TCP.

Two operational facts separate people who have run DNSSEC from people who have read about it:

• Proving non-existence leaks names. NSEC proves "nothing exists between alpha and delta", which lets anyone walk the chain and list every name in the zone. NSEC3 hashes the names to slow that down, but the hashes can be guessed offline for common names. If your zone contains names that reveal internal systems, assume they are enumerable.
• Failures are outages, not warnings. A validating resolver returns SERVFAIL for a domain whose signatures expired or whose DS no longer matches its keys. The root zone's own key-signing key was rolled for the first time in October 2018, after a year's delay to make sure resolvers had picked up the new trust anchor; that caution is the model. The second rollover, to KSK-2024 (key tag 38696), took effect on 11 October 2026, so a resolver that lacks the new trust anchor can fail validation for chains that depend on it. Check anchor state and validation results rather than assuming all resolvers updated automatically. In September 2021 Slack's DNSSEC rollout caused an outage for users behind validating resolvers and was rolled back.

DNSSEC also does nothing for the last hop. A validating recursive resolver tells the stub "this answer is authentic" with a single unauthenticated flag bit; an attacker between stub and resolver can flip it or replace the whole answer. Encrypted DNS to the validating resolver, or validation on the device, closes that hop.

Encrypted DNS: privacy for the first hop

DNS over TLS (DoT, RFC 7858, port 853) and DNS over HTTPS (DoH, RFC 8484) wrap the stub-to-resolver conversation in TLS. DNS over QUIC (RFC 9250) does the same over QUIC. They protect the queries from the local network and stop an on-path attacker from forging answers on that hop. They do not:

• make the resolver honest, or validate DNSSEC unless the resolver does;
• hide the queries from the resolver operator, who now sees every name the device looks up;
• hide the destination: the IP address the device connects to next, and usually the TLS server name, are still visible.

For enterprises, DoH has a second edge. Browsers that send DoH to a public resolver bypass the corporate resolver, which may be where malware-domain blocking and split-horizon internal names live. The usual answer is to manage the setting on company devices and run DoH on the corporate resolver itself, rather than to block port 443 to known resolvers, which is a losing game.

DNSSEC, encrypted DNS and TLS compared

Domain takeover: the attack that skips the cache

Every control above protects the path from the true records to the client. Domain takeover changes the true records. Between late 2018 and 2019 the DNSpionage and Sea Turtle campaigns, both reported by Cisco Talos, hijacked DNS for government and infrastructure organisations by compromising registrars, registries and DNS provider accounts, then obtained valid certificates for the hijacked names. The US Cybersecurity and Infrastructure Security Agency issued Emergency Directive 19-01 in January 2019 ordering federal agencies to audit DNS records, change DNS account passwords, add MFA and monitor Certificate Transparency.

What makes takeover so effective:

• The attacker can now pass a certificate authority's domain validation, because the CA checks DNS or HTTP at the hijacked address. They get a valid certificate and TLS stops helping.
• If the zone is DNSSEC-signed and the attacker controls the DNS provider account, the provider signs the attacker's records. DNSSEC authenticates the source; it cannot tell a legitimate change from a malicious one.

The controls are account controls, not protocol controls: registry lock (changes need out-of-band confirmation at the registry), registrar MFA with phishing-resistant factors, a short list of people who can change NS and DS records, alerts on any change to them, CAA records limiting which CAs may issue, and Certificate Transparency monitoring to catch a certificate you did not request within hours.

Subdomain takeover

A dangling DNS record becomes a takeover risk when its target can be reclaimed by another account. The pattern:

1. A team creates promo.example.com as a CNAME to a cloud-hosted resource (a storage bucket website, an app platform hostname, a CDN endpoint).
2. The campaign ends and the cloud resource is deleted. The CNAME is not.
3. If the provider permits reuse of that resource name or domain binding without renewed ownership verification, another account may claim it and serve content on promo.example.com. A stale record alone does not prove that a takeover is possible.

The consequences go beyond defacement: the attacker's page is same-site with your main domain, so cookies scoped to .example.com are sent to it, it may pass CORS allowlists that trust *.example.com, and it can host convincing phishing under your name. Prevention is ordering (delete the DNS record first, the resource second), inventory (every CNAME target is checked against what you still own) and avoiding wildcard trust of your own subdomains.

DNS as a weapon and a channel

DNS is also used by attackers against third parties and as a covert channel.

• Reflection and amplification. A small spoofed-source query to an open resolver can return a much larger answer to the victim. US-CERT's alert TA14-017A put DNS amplification at 28 to 54 times. Defences: do not run open resolvers, apply response rate limiting on authoritative servers, and ingress filtering (BCP 38) so networks drop packets with spoofed source addresses.
• Tunnelling and exfiltration. Query names can carry data to an external authoritative server through the workload's permitted resolver. An AI sandbox that blocks HTTP but allows arbitrary DNS names still has an outbound channel. Look for unusual label lengths, query volumes and subdomain counts; route DNS through controlled resolvers and restrict names where the workload has a defined set of dependencies.
• DNS rebinding. One hostname can return different addresses over time. Browser origin checks use the scheme, hostname and port, so a changed address can expose a reachable local service if other protections permit the request. TLS validation and browser local-network restrictions also matter; this is not a universal browser bypass. Local services should validate the expected host and require authentication. Server-side SSRF has a related race: checking one resolution and connecting after a second resolution can reach an address that was never approved.

DNS address binding versus certificate pinning

In an SSRF defence, pinning the resolved address means connecting to the address the policy actually approved. Certificate pinning constrains a TLS peer's certificate or key. These checks answer different questions: where may this request go, and which peer may authenticate there?

For a server-side URL fetcher, parse the URL once, restrict schemes and ports, and resolve through a controlled path. Evaluate all candidate A and AAAA addresses, including special-use and IPv4-mapped IPv6 forms, against the fetcher's destination policy. Bind connection establishment to an approved result. Preserve the original hostname for HTTP authority, TLS SNI and certificate hostname validation; disabling TLS checks to connect by IP defeats peer authentication.

Disable automatic redirects unless each hop goes through the same policy. Review proxy-side DNS, retries, connection pools and alternate addresses: none may create a route around the check. Revalidate on a new connection instead of keeping an indefinite IP pin that breaks legitimate address changes. Network egress restrictions provide a second boundary when a URL parser or client library behaves unexpectedly.

Domain hygiene for defenders

• Registrar lock and MFA; limit who can change DNS; alert on record changes.
• DNSSEC signing where operationally supported.
• CAA records listing which CAs may issue certificates for the domain.
• Certificate Transparency monitoring for unexpected certificates.
• Regular sweeps for dangling CNAMEs and stale records.
• SPF, DKIM and DMARC so the domain's mail identity cannot be spoofed.

Worked example: a poisoned resolver at a branch office

Users at one office report the payroll site "has a certificate error". Investigation shows the branch's resolver returns an unfamiliar IP for the payroll domain. TLS validation failed because the attacker had no trusted certificate: the incident is an attempted credential theft stopped by validation (and by HSTS, which prevented clicking through). Actions: flush and fix the resolver, enable DNSSEC validation, check for other poisoned names, and investigate how the attacker reached the resolver.

Push the example further, because interviewers will:

• Blast radius. Every user of that resolver received the bad answer for the record's TTL. If the forged record carried a TTL of 86,400 seconds, flushing the cache is mandatory; waiting for expiry means a day of exposure.
• What else to check. Was the resolver open to the internet (it should answer only internal clients)? Is it patched against known side channels? Did any non-HTTPS service (an LDAP server, an internal update feed) resolve through it during the window? Those had no certificate check to save them.
• What validation would have changed. With DNSSEC validation on the resolver and the payroll domain signed, the forged answer would have failed validation and users would have seen a resolution failure instead of a certificate warning: still an outage, but caught one layer earlier and logged at the resolver.

Misconceptions interviewers listen for

• "DoH makes DNS secure." It makes the first hop private and tamper-evident. The resolver can still lie or be poisoned.
• "DNSSEC encrypts DNS." It signs. Every query and answer is still readable.
• "If DNS is hijacked, TLS saves us." Only until the attacker uses the hijack to pass domain validation and obtain a real certificate. Account security and CT monitoring are the defence.
• "Subdomain takeover is just defacement." Same-site position means cookies, CORS trust and credible phishing.
• "We block outbound traffic, so data can't leave." Not if DNS resolution to arbitrary names is allowed.

What if · interview follow-ups

Hold your answer as the constraints change

You run DNS for a company with a public domain, internal names served by a corporate resolver, laptops that roam, and a sandbox where an AI coding agent runs generated code. The interviewer probes one change at a time.

1. 1

   Start here

   What if an off-path attacker is racing forged answers at your corporate resolver?

   Nudge meAnswer it out loud, then reveal

Revising, not practising? Show every answer

Primary references

• RFC 5452: matching DNS responses and resisting forged answers, checked 6 November 2026.
• RFC 4033: DNSSEC services and limitations, checked 6 November 2026.

References for the mechanisms discussed above, accessed 6 November 2026:

• OWASP SSRF prevention: DNS resolution, address checks and redirects.
• RFC 9525: authenticate the expected TLS service identity.

How this shows up in interviews

DNS questions test whether you separate authenticity (DNSSEC) from privacy (DoH/DoT) and whether you remember the registrar, the most direct path to a domain. Strong candidates also bring DNS into questions that are not nominally about it: rebinding in an SSRF answer, tunnelling in a sandbox or egress answer, subdomain takeover in a cookie-scoping answer, and domain validation in a PKI answer.

Say it in 30 seconds: "A lookup goes stub, recursive resolver, then root, TLD and authoritative servers, with caching. Attackers forge answers into caches, run malicious resolvers, take over the domain at the registrar, or claim dangling records. DNSSEC lets resolvers reject forged records but encrypts nothing; DoH and DoT encrypt the client-to-resolver hop but trust the resolver. TLS validation is the backstop for HTTPS, and registrar security protects the source."

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

1. 1What is a subdomain takeover, and how do you prevent it?

   Answer it, then reveal

2. 2Why can a mistake in DNSSEC operations take a domain offline?

   Answer it, then reveal

3. 3Why did Kaminsky's 2008 technique make cache poisoning practical when it had been mostly theoretical?

   Answer it, then reveal

4. 4A domain is DNSSEC-signed. An attacker takes over the company's DNS hosting account and changes the A record. Will validating resolvers reject it?

   Answer it, then reveal

5. 5Why is DNS a concern when sandboxing an AI agent that runs generated code?

   Answer it, then reveal