What is DNSSEC? How do digital signatures prevent DNS cache poisoning?!

　　An attacker sits at a network node, monitoring the DNS query packets flowing past. They observe you sending a query to a recursive server: "What is the IP address for bank.example?" Before the legitimate authoritative server can reply, the attacker sends you a forged response packet: "The IP for bank.example is 6.6.6.6." Your recursive server accepts this response and stores it in its cache. For the next few hours, any user querying that recursive server for bank.example will be directed to 6.6.6.6.

　　This is the classic scenario of DNS cache poisoning. It does not require advanced technical skills from the attacker; they simply need to present a forged "ID card" at the right moment. DNSSEC is designed to ensure that such a forged ID is immediately detected and rejected during the verification process.

　　The Root Cause: Blind Trust in DNS

　　The DNS protocol was designed in 1983, when the Internet was still a relatively closed academic network; its designers assumed that all network participants were acting in good faith. Queries and responses are transmitted via UDP without handshakes or identity authentication. When a recursive server receives a response packet, it checks only two things: whether the Transaction ID matches and whether the source port is correct. If they match, the server trusts the response.

　　This "first-come, first-served" trust model is the foundation that makes cache poisoning possible.

　　RFC 4033 bluntly describes the situation without DNSSEC: a DNS resolver sends out a query and unquestioningly accepts the first response it receives. If that response is forged, the resolver continues to use the incorrect address until the cache entry expires.

　　The problem arises when the poisoned system is not an individual user's computer but an ISP's recursive server; in that case, every user relying on that server is affected. This illustrates the amplification effect of DNS cache poisoning. The Core of DNSSEC: Digitally Signing Every DNS Record

　　In a nutshell, DNSSEC (Domain Name System Security Extensions) enables cryptographic verification of the origin and integrity of DNS data.

　　It does not encrypt DNS data; DNS records are still transmitted in plaintext. Instead, it attaches a digital signature to the DNS record. This signature is generated by the authoritative DNS server by performing a cryptographic operation on the record's content using a private key known only to itself. Anyone possessing the corresponding public key can verify whether the signature matches the record's content.

　　To use an analogy: traditional DNS responses are like handwritten notes where anyone could forge the handwriting. DNSSEC adds a "wax seal" to the note—a seal that only the sender could create. While anyone can verify the seal's authenticity using a public mold, forging the seal itself requires possession of that private key.

　　Specifically regarding the DNS message structure, DNSSEC introduces four new record types:

　　RRSIG (Resource Record Signature): The digital signature itself. Returned alongside the DNS response, it contains information such as the signature value, the signature's validity period, and the signer's name.

　　DNSKEY (DNS Public Key): The public key. Authoritative servers use this to publish the public key needed to verify signatures. Anyone can retrieve this public key via a DNS query.

　　DS (Delegation Signer): Stored in the parent zone, this record holds the hash value used to verify the child zone's DNSKEY. It is a crucial link in the "chain of trust."

　　NSEC/NSEC3 (Next Secure): Used to prove that "a specific record does not exist." Without DNSSEC, an attacker could forge a "domain does not exist" response; with NSEC, the authoritative server can sign the fact of non-existence itself, allowing the resolver to verify that the "negative response" is authentic. Chain of Trust: A Layered "Guarantee" Starting from the Root Zone

　　Digital signatures alone are insufficient, as an attacker could fabricate an entire set of data—forging the DNSKEY and RRSIG—and then claim the data has "passed verification."

　　DNSSEC addresses this issue through hierarchical guarantees, known as a "chain of trust."

　　The logic works as follows: The ICANN root zone's Key Signing Key (KSK) serves as the "trust anchor" for the entire system. The root zone uses its private key to sign the DS record for the .com zone, effectively vouching that the .com zone's public key is trustworthy. The .com zone then uses its own private key to sign the DS record for the example.com zone, vouching for the trustworthiness of example.com's public key. Finally, example.com uses its own private key to sign its own DNS records (such as A records or MX records).

　　When a recursive resolver with DNSSEC validation enabled receives a response, it traces this chain of trust from the root down to the target domain. At each step, it performs checks: Is the parent zone's signature valid? Does the child zone's public key hash match the DS record? Does the final data signature match the data itself?

　　If any step fails to validate, the resolver marks the response as "Bogus" (forged). Depending on its configuration, it will either return an error (SERVFAIL) or refuse to use the data. No matter how authentic a forged response packet from an attacker might appear, it cannot pass verification against this cryptographic chain.

　　How do digital signatures prevent cache poisoning?

　　Let's revisit the attack scenario.

　　An attacker can still send a forged response packet to the recursive server before the legitimate authoritative server does. Transaction... The ID and source port were guessed correctly, but the forged packet lacked a valid RRSIG signature.

　　Without a signature—or if signature verification fails—the recursive server will not accept the data as "Secure." For a resolver with DNSSEC validation enabled, a response that fails verification is treated as invalid.

　　This is how DNSSEC deals a fatal blow to cache poisoning: successful poisoning relies on the recursive server "trusting" the forged data. DNSSEC makes that trust conditional—you must first prove your authenticity.

　　RFC 4033 defines four states that a validating resolver can determine: Secure (trust anchor exists, chain of trust is complete, and all signatures verify); Insecure (the zone is proven to be inherently insecure—e.g., the parent zone explicitly declares the absence of a DS record); Bogus (a security delegation exists but verification fails); and Indeterminate (no trust anchor exists, making determination impossible). Forged data from a cache poisoning attempt is marked as "Bogus" by a validating resolver and subsequently discarded.

　　What does DNSSEC *not* do?

　　Understanding the limitations of DNSSEC is just as important as understanding its functions.

　　DNSSEC does not encrypt DNS queries and responses. Data is still transmitted in plaintext; a man-in-the-middle can see which domain you are querying but cannot tamper with the response without being detected. To prevent eavesdropping, protocols like DoT or DoH are required.

　　DNSSEC does not protect the origin server itself. It safeguards the authenticity of the mapping between a domain name and an IP address, but it does not ensure the security of the server associated with that IP address.

　　DNSSEC is not a substitute for SSL certificates. Verisign's documentation offers an insightful... In summary: DNSSEC ensures users are directed to the correct website, while SSL certificates verify the site's identity and encrypt communications. The two are complementary and essential to one another.

　　The Reality of Deployment: Why You Rarely "Notice" It

　　The DNSSEC root zone was signed in 2010, and major top-level domains (TLDs) like .com and .net have long supported it. However, average users rarely perceive the presence of DNSSEC, primarily due to deployment rates.

　　For a domain to benefit from DNSSEC protection, three conditions must be met: the registry must support DNSSEC, the domain holder must actively enable signing, and the recursive resolver (usually provided by the ISP) must enable validation. If any of these links is missing, DNSSEC protection will not take effect. ICANN data from 2012 showed that less than 1% of second-level domains were signed; while this figure has risen over the years, there is still a long way to go before it becomes enabled by default.

　　Consequently, for most average users, daily DNS resolution still operates without DNSSEC validation. The risk of DNS cache poisoning remains at the protocol level—though whether an attacker chooses to target your specific resolver is a different matter.