Network Security / Protocol Analysis

DNS Security

Domain Name System (DNS) security has separate goals: return the intended data, authenticate signed data where DNSSEC is deployed, protect selected DNS transport hops from observation or modification, keep resolution available, and remove stale delegations. No single mechanism supplies all of these properties.

Follow the actors and caches

1. A stub resolver in an application or operating system sends a question to a configured recursive resolver.
2. The recursive resolver answers from cache or follows delegations through root, top-level-domain, and authoritative name servers.
3. An authoritative server answers for data in a zone. The zone operator controls the records; the registrar and registry maintain the parent-side delegation.
4. A validating resolver additionally evaluates DNSSEC signatures and the chain from a configured trust anchor. Validation can occur on the client, recursive resolver, or both.

The stub normally trusts its selected recursive resolver unless it validates independently. Split-horizon or private DNS may intentionally return different answers by network or identity; resolver selection and search-suffix policy therefore affect both security and correctness.

Record types carry different risks

Cache poisoning is a response-acceptance race

Classic DNS over UDP does not cryptographically authenticate a response. An off-path forger must make a response arrive before the authentic answer and match the resolver’s acceptance checks, including the question, query identifier, expected source address, and destination address and port described by RFC 5452. The Kaminsky technique repeatedly asks for unpredictable names so the resolver generates new upstream queries and the attacker gets repeated races against a delegation-related answer.

Conceptual attack path: a forged response must win the race and satisfy every resolver acceptance check

Source-port and query-ID randomization increase the off-path guessing space; bailiwick checks and response matching reduce what a resolver accepts. These hardening measures lower forgery probability but do not add cryptographic origin authentication. DNSSEC provides that property for signed data when a validator has a valid chain; TLS-protected resolver transport protects only the encrypted hop and its authenticated endpoint.

DNSSEC authenticates signed RRsets

DNSSEC signs resource-record sets (RRsets) and builds a chain across zone cuts:

Conceptual validation chain: each DS authenticates selected child DNSKEY data; an RRSIG then authenticates the answer RRset

• DNSKEY: Publishes a zone public key. Operators often separate Key Signing Key (KSK) and Zone Signing Key (ZSK) roles, but that operational split is not required for every zone.
• RRSIG: Contains a signature produced by the private key corresponding to the identified DNSKEY. It is not necessarily produced by a key with one universal “ZSK” role.
• DS: The parent publishes a digest over the canonical child owner name concatenated with the child DNSKEY RDATA—not merely a hash of raw public-key bytes.
• NSEC / NSEC3: Authenticated-denial records prove that a requested name or type does not exist. NSEC3 changes the disclosure trade-off but does not hide all zone structure or remove enumeration risk.

A validator classifies an answer according to the chain and local policy. Secure data validates to a trust anchor; insecure data has a proven unsigned delegation; bogus data should validate but fails; indeterminate data cannot yet be classified. A broken signature, missing parent/child rollover data, expired signature, incorrect clock, stale trust anchor, or unreachable authoritative server can turn a signed deployment into a resolution outage.

The DNSSEC-related header flags answer different questions:

• DO in the EDNS request asks the server to include DNSSEC records; it does not request or prove validation by itself.
• CD asks a recursive resolver to disable its normal checking for that query so the requester can inspect or validate data itself.
• AD in a response is meaningful only when received over a trusted channel from a resolver whose validation behavior is trusted. It is not a portable proof when an attacker can alter the response header.

DNSSEC and encrypted DNS solve different problems

DoH, DoT, and DoQ can carry DNSSEC records and validation results; they do not inherently disable DNSSEC. They authenticate and encrypt a transport endpoint, not the DNS data across every resolver-to-authority hop. The privacy gain therefore depends on which resolver is selected, whether the local network can force or bypass that choice, resolver logging and retention, and whether validation occurs locally.

Reduce data exposure and operate the lifecycle

• QNAME minimization (RFC 9156) sends only the name portion needed at each delegation step. It reduces disclosure to intermediate authoritative servers but not to the stub’s recursive resolver; cold-cache resolution can require more queries.
• Aggressive use of authenticated denial (RFC 8198) lets a validating resolver synthesize some negative answers from cached NSEC/NSEC3 data, reducing authoritative load. Cache policy and proof coverage limit where it applies.
• Coordinate DNSKEY, DS, and signature timing during rollover. Publish overlap, account for TTLs and caches, verify the parent update, and retain an emergency plan before removing the old validation path.
• Monitor validation failures, SERVFAIL rates, signature inception/expiration, DS/DNSKEY mismatch, authoritative reachability, unexpected delegation changes, resolver configuration drift, and query-volume anomalies.
• Inventory DNS records with the external resource lifecycle. Remove or replace aliases before a third-party target becomes claimable; investigate possible exposure if takeover occurred.
• Define recovery for registrar compromise, lost signing keys, bad DS publication, trust-anchor failure, resolver outage, and accidental private/public-zone divergence.

Inspect behavior without treating one command as proof

# Request DNSSEC records. Presence of RRSIG shows signed data was returned;
# it does not prove that this client validated the chain.
dig +dnssec nist.gov A +noall +answer

# Ask the configured recursive resolver not to perform its normal checking.
# Comparing this with the normal response can help diagnose validation failure.
dig +dnssec +cdflag nist.gov A

# Validate with delv when the installed build has crypto support and a usable
# trust anchor. Output varies with software, resolver path, cache, and time.
delv nist.gov A

Record the resolver address, software version, trust-anchor source, system time, network path, and execution time with diagnostic evidence. A successful lookup proves only the tested name, type, path, validator state, and moment; it does not prove every record or future rollover is sound.

Primary references

• RFC 5452: Measures for Making DNS More Resilient against Forged Answers — verified response-matching conditions, race requirements, and forgery hardening boundaries.
• RFC 4033, RFC 4034, and RFC 4035 — verified DNSSEC records, DS digest input, validation states, authenticated denial, and chain behavior.
• RFC 6781: DNSSEC Operational Practices, Version 2 — verified rollover, timing, parent coordination, and operational failure considerations.
• Microsoft: Prevent dangling DNS entries and avoid subdomain takeover — verified the deprovisioned-resource lifecycle and remediation boundary for dangling aliases.