DNSSEC and DNS’ Fundamental Flaw

Before diving into DNSSEC (Domain Name System Security Extensions,) let’s cover the fundamental flaw in the original design of DNS: trust. DNS was built on trust, not security. DNSSEC does not encrypt DNS - it verifies it.

In standard DNS, when a recursive resolver asks an authoritative server for an IP address, it looks for two things to verify the answer:

1. The Transaction ID (a 16-bit number.)
2. The Source Port

If an attacker can guess those two numbers and send a fake response to the resolver faster than the real authoritative server can, the resolver will accept the fake answer as truth.

DNS Spoofing and Cache Poisoning

Spoofing is the act of sending a fraudulent DNS response to a resolver. The resolver is “spoofed” into thinking the attacker is the legitimate authoritative server.

DNS Cache Poisoning is the result of a successful spoof. Once the resolver accepts the fake IP, i.e., sending a user to a fake banking site, it caches the record. For the next few hours, or until the TTL expires, every single user using that resolver will be sent to the attacker’s site, regardless of whether the authoritative server is now sending the correct data.

Steven Bellovin identified key weaknesses in DNS in 1997, and along with other discovered weaknesses, led to the current iteration of DNSSEC, released in 2005. About five years later, the DNS root zone was signed, enabling a global chain of trust.

Prior to the release of DNSSEC, DNS poisoning was a sore spot for many network administrators. An instructor that led the Windows 2000 MCSE bootcamp I attended in 2002 gave me the opportunity to talk about DNS’ relationship with Active Directory, and rushed me back to my seat once he heard me say “poisoning.”

As the day began to wind down, he explained that he was more than happy to talk about the topic – but knew that it would have led the class down a rabbit hole and would take time needed to prep for an upcoming exam – and it turned into a 2-hour conversation at a pizzeria with a handful of other students.

The Mechanics of DNSSEC

DNSSEC introduces several new Resource Records to handle the cryptography:

RRSIG - Resource Record Signature

Instead of just providing an A record, the server provides the A record and an RRSIG. The RRSIG is a digital signature of the record, created using a private key.

DNSKEY - DNS Public Key

To verify the RRSIG, the resolver needs the public key. The DNSKEY record contains the public key that corresponds to the private key used to sign the zone.

DS - Delegation Signer

Here’s the catch – how do you know the DNSKEY itself isn’t a fake? An attacker could spoof both the A record and the DNSKEY… To solve this, DNSSEC uses a Chain of Trust. The parent zone, i.e., the .com registry, stores a cryptographic has of the child’s public key – this is the DS record.

The Chain of Trust

DNSSEC works by building a chain of verification from the bottom up to the very top of the Internet.

1. The Domain Level: The resolver asks for foundry81.com. It receives the A record and RRSIG. It then fetches the DNSKEY for foundry81.com to verify the signature.
2. The TLD Level: To ensure the foundry81.com DNSKEY is legitimate, the resolver asks the .com TLD servers for the DS record of foundry81.com. If the DS record matches the DNSKEY, the domain is verified.
3. The Root Level: The ensure the .com TLD is legitimate, the resolver asks the Root Servers for the DS record of .com.
4. The Trust Anchor: Finally, the resolver needs to verify the Root. Since there is no “parent” above root, the root’s public key is hard-coded into the resolver’s software – this is called the Trust Anchor.

When the Chain is Broken

If any link in this chain is broken – the signatures don’t match – the resolver returns a SERVFAIL error to the user and the page will not load.

If an attacker attempts to poison the cache of a DNSSEC-enabled resolver by sending a fake RRSIG and a fake DNSKEY, the resolver will still check the DS record at the TLD level. The fake DNSKEY will not match the DS record stored at the TLD and the resolver rejects the packet – the cache remains clean and the attack fails.

There are scenarios unrelated to malicious actions that can lead to DNSSEC failures, including incorrect DS records, expired RRSIG records, and clock skew.

DNSSEC in a Homelab?

Absolutely! DNSSEC validation (something BIND enables by default,) makes a lot of sense and there’s very little downside:

• No key management
• No signing overhead
• No operational burden -You get protection from bad upstream responses

DNSSEC signing for your own domain is a separate configuration and introduces additional operational complexity. For most Homelab environments, it’s optional unless you’re hosting publicly accessible DNS or want to learn how it works in practice.

Access Your Homelab from Anywhere.

DNSSEC adds a layer of verification to DNS, but it’s only one piece of a larger trust model.

Once you’re accessing services remotely, identity shifts up the stack. That’s where Twingate comes into play - take a look at how that works without opening ports.