DNSSEC and DNS Filtering

Plain DNS offers no authenticity. Two complementary defenses address this: DNSSEC proves that answers are genuine and untampered, while DNS filtering blocks resolution of known-bad names. Together they protect integrity and reduce attack surface.

This lesson covers how each works and where they fit in a layered DNS security strategy.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS data. It guarantees:

• Origin authenticity — the answer came from the real zone owner.
• Data integrity — the answer was not modified in transit.

Importantly, DNSSEC does not provide confidentiality. Queries and answers remain in cleartext; for privacy you still need DoT/DoH.

Each record set in a signed zone gets an RRSIG record: a digital signature over that data. The matching public key is published as a DNSKEY record.

A validating resolver fetches the RRSIG and DNSKEY, then verifies the signature. If it fails, the answer is rejected as bogus rather than served to the client.

Trust flows down the hierarchy. A parent zone publishes a DS (Delegation Signer) record that hashes the child zone DNSKEY. The chain runs: root → TLD → your domain.

A validating resolver starts from the hardcoded root trust anchor and follows DS records down. If any link is missing or wrong, validation fails. Publishing the DS at your registrar is what activates DNSSEC for your domain.

Zones use two key roles:

• ZSK (Zone Signing Key) — signs the actual records; rotated frequently.
• KSK (Key Signing Key) — signs the DNSKEY set; longer-lived and referenced by the parent DS.

Splitting roles lets you rotate the ZSK without touching the parent delegation, simplifying key management.

DNSSEC must also prove that a name does not exist. NSEC records sign the gaps between existing names, but they let attackers walk and enumerate the entire zone.

NSEC3 fixes this by signing hashed names instead of plaintext, hindering zone enumeration. Prefer NSEC3 (or NSEC3 opt-out) for zones you do not want fully crawlable.

Be realistic about scope:

• No confidentiality, only integrity and authenticity.
• Validation must happen at a trusted resolver; the last mile to the stub is still unprotected without DoT/DoH.
• Misconfigured or expired signatures cause outages, so monitor signature validity.
• Larger responses increase amplification potential if open recursion is left on.

DNS filtering uses the resolver as a policy enforcement point. When a client looks up a malicious or unwanted domain, the resolver refuses or rewrites the answer (often to a sinkhole or block page).

It is cheap, fast, and protocol-agnostic: blocking the lookup stops malware C2, phishing, and unwanted categories before a connection is even attempted.

RPZ is a standard way to apply DNS firewall policy. The resolver loads policy zones (local or from threat-intel feeds) and can:

• Return NXDOMAIN (name does not exist).
• Return NODATA.
• Redirect to a sinkhole or walled-garden IP.
• Pass through with logging.

Sinkholing is powerful for incident response: redirect known C2 domains and watch which hosts try to reach them.

Filtering value depends on data quality. Feed the resolver with:

• Curated malware/phishing/C2 indicator lists.
• Newly-registered and low-reputation domain feeds (often malicious).
• Category policies (e.g. block known anonymizers on corporate devices).

Pair filtering with logging so blocked lookups become detection signals, not just silent denials.

The two defenses are complementary, not competing:

• DNSSEC ensures the answers you do get are authentic and untampered.
• Filtering/RPZ ensures you never resolve known-bad names in the first place.

Deploy both on validating internal resolvers, add DoT/DoH for last-mile privacy, enforce egress controls, and you have a strong, layered DNS security posture.

Confirm what DNSSEC actually guarantees.

DNSSEC authenticates DNS answers using RRSIG signatures, DNSKEY/DS chain of trust from the root anchor, and NSEC/NSEC3 for authenticated denial, but provides no confidentiality. DNS filtering (RPZ, sinkholing, threat feeds) prevents resolution of known-bad names and turns blocks into detections.

Used together on validating internal resolvers, with DoT/DoH and egress controls, they form a layered defense against the DNS attacks covered in this course.