After deploying DNSSEC for example.com, users of DNSSEC-validating resolvers report they cannot reach the site at all. Users of non-validating resolvers have no problem. What is the most likely cause?
AThe chain of trust is broken — for example, the DS record in the .com parent zone was not updated to match the zone's KSK, so validators cannot complete the validation chain and return SERVFAIL
BDNSSEC encrypted the DNS responses in a format that validating resolvers cannot decrypt without the private key
CThe zone's A records were inadvertently deleted when DNSSEC signing was enabled
DNon-validating resolvers are performing a DNS cache poisoning attack, making the site appear reachable to them
DNSSEC validation requires an unbroken chain of trust from the root through parent zones to the signed zone. If the DS record in the .com zone doesn't match the zone's KSK — a common error during deployment or key rollover — validating resolvers cannot verify the zone's DNSKEY, causing them to reject all responses with SERVFAIL. Non-validating resolvers simply ignore signatures and accept whatever answer they receive. DNSSEC does not encrypt responses; it signs them — so decryption is not involved. The broken chain failure mode is why DNSSEC deployments require careful coordination between the zone operator and the parent zone registry.
Question 2 Multiple Choice
A network administrator deploys DNSSEC for their company's domain. A colleague says: 'Great — now no one can see what websites our employees are visiting.' Is the colleague correct?
AYes — DNSSEC cryptographically encrypts DNS queries and responses, hiding domain lookups from observers
BNo — DNSSEC authenticates DNS responses to prevent tampering, but queries and responses still travel in plaintext; observers can still see which domains are being looked up
CYes — the chain of trust prevents third parties from intercepting DNS traffic at any point in the network
DNo — DNSSEC only protects the path from authoritative nameservers to resolvers, not from clients to resolvers
DNSSEC provides authentication and integrity, not confidentiality. DNS queries and responses remain unencrypted plaintext — anyone who can observe the network traffic can still see which domains are being resolved. DNSSEC's signatures allow a receiver to verify that a response genuinely came from the authoritative source and was not modified in transit, but they reveal nothing about the content. Hiding DNS queries requires separate protocols like DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), which encrypt the entire DNS conversation.
Question 3 True / False
DNSSEC validation chains trust from the root zone through parent zones via DS records down to the target zone, so a validating resolver must trust the root zone's public keys as its starting point.
TTrue
FFalse
Answer: True
The root zone's DNSKEY records are the trust anchors: their public keys are hardcoded into validating resolvers. From there, each parent zone publishes a DS (Delegation Signer) record containing a hash of the child zone's KSK. The resolver verifies the child's DNSKEY against the parent's DS record, which was itself verified using the grandparent's keys, and so on up to the root. This hierarchical chain means that trusting the root is both the starting assumption and the point of maximum leverage — if a root key were compromised, the entire DNSSEC system would be undermined.
Question 4 True / False
DNSSEC protects DNS responses from eavesdropping because most DNS records are encrypted with the Zone-Signing Key before transmission.
TTrue
FFalse
Answer: False
DNSSEC does not encrypt DNS records — it signs them. The Zone-Signing Key is used to create RRSIG signatures that prove a record is authentic and unmodified, but the records themselves are transmitted in plaintext, just as in ordinary DNS. An observer watching the network can read every DNS response, including DNSSEC-signed ones. Encryption of DNS traffic requires DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), which wrap DNS messages in TLS sessions. DNSSEC's goal is authentication (did this response come from the legitimate authoritative server?), not confidentiality (can observers see the response?).
Question 5 Short Answer
Explain why a break in the DNSSEC chain of trust causes a domain to become completely unreachable for DNSSEC-validating resolvers, even if the domain's DNS records are technically correct.
Think about your answer, then reveal below.
Model answer: A validating resolver must verify every link in the chain from the root trust anchor to the zone's actual records: root DNSKEY → .com DS record → .com DNSKEY → example.com DS record → example.com DNSKEY → RRSIG signatures on the A record. If any link fails — an expired RRSIG, a DS record that doesn't match the zone's KSK, or a missing DNSKEY — the resolver cannot complete the validation chain. Rather than accept an unvalidated response (which could be a forgery), it returns SERVFAIL, making the domain unreachable. The resolver treats a broken chain identically to a detected attack, because it has no way to distinguish misconfiguration from tampering.
This 'fail closed' design is intentional: the security model assumes that an inability to verify authenticity is as dangerous as a detected attack. The operational consequence is that DNSSEC misconfigurations look exactly like outages to end users with validating resolvers.