DNSSEC

DNSSEC — DNS Security Extensions — solves one specific problem: a resolver cannot, by default, prove that a DNS answer is genuine. The recursive chain from root to authoritative is mostly unauthenticated. An attacker on the network path between the resolver and the authoritative server can inject forged answers, and the resolver has no way to detect the forgery.

DNSSEC adds cryptographic signatures to DNS responses. When DNSSEC is deployed end-to-end, a resolver can validate that the answer it received was actually published by the authoritative zone owner and wasn’t tampered with in transit.

It’s a clean idea, with two awkward realities: deployment is rare, and most clients won’t ask you to set it up.

How DNSSEC works in one minute

The zone owner generates a key pair. The public key is published in DNS as a DNSKEY record. Every record in the zone is signed with the matching private key, producing RRSIG records published alongside the originals. A validating recursive resolver pulls the records, pulls the RRSIGs, pulls the DNSKEY, and verifies the signatures.

That handles the zone itself. The chain back to the root works through DS (Delegation Signer) records published in the parent zone. The parent’s DS record commits to a hash of the child’s DNSKEY. The parent zone is in turn signed by its parent, and so on up to the root, whose key is hard-coded into every validating resolver. This chain is what gives DNSSEC its strength — there’s no point on the path that an attacker can insert without breaking the cryptography.

Why most domains skip it

Three reasons:

1. Operational risk is high. A DNSSEC misconfiguration takes a zone offline for validating resolvers. The cryptography has no margin for error — wrong signatures, expired signatures, missing DS records, or key rotation gone wrong, and the domain disappears for everyone whose resolver validates DNSSEC. The classic incident: a registrar update changes the DS record at the wrong time and email goes dark for a day.

2. Adoption is asymmetric. A validating resolver gets the protection. Resolvers that don’t validate (still most of the public internet) ignore the signatures and accept any answer. So deploying DNSSEC on your own zone helps the subset of users whose resolvers validate — which is real, but not universal.

3. The threat model is narrow. DNSSEC defends against on-path tampering of DNS responses. The dominant threats we encounter in MSP work — phishing, credential theft, mailbox compromise — are upstream of DNS. DNSSEC doesn’t help with any of them.

This is why you’ll see DNSSEC at large financial institutions, government domains, and TLDs themselves — places where the cost of being spoofed is high enough to justify the operational overhead — and rarely at the SMB clients we serve. It’s not wrong for SMB; it’s just unusual.

What Cathedra checks

DnsHygieneCheck runs a deliberately lightweight probe. It calls dns_get_record($domain, DNS_ANY) and looks for any record of type DNSKEY in the result.

When a DNSKEY appears:

status: pass
“DNSKEY record detected. DNSSEC appears to be enabled for this domain.”

When no DNSKEY appears:

status: info / severity: null
“No DNSKEY record detected via DNS_ANY. DNSSEC may not be enabled or is not verifiable from this server.”
Recommendation: “Consider enabling DNSSEC at your registrar for additional DNS integrity.”

Note the wording: may not be enabled or is not verifiable from this server. The check is intentionally soft because DNS_ANY is not a reliable way to enumerate every record type on a zone — many authoritative servers refuse ANY queries entirely, or return only a subset. Cathedra’s probe is good enough to flag DNSSEC as present when it is, but a no DNSKEY result doesn’t guarantee DNSSEC isn’t deployed.

The status is info, not warning. Like CAA, this is a hardening opportunity, not a defect.

Confirming DNSSEC manually

If the Cathedra result is ambiguous, confirm with a direct query:

dig isidoregroup.com DNSKEY +short

If DNSKEY records come back, DNSSEC is deployed at the zone level. To check the full chain — including the DS record at the parent — use:

dig isidoregroup.com +dnssec +trace

The +dnssec flag asks for DNSSEC records in the response. If you see RRSIG records alongside the answer section, the zone is signed. If dig reports ad (authenticated data) in the flags line, your local resolver validated the signatures successfully.

Another quick sanity check: the DS record at the parent zone tells you the registrar has the public key committed. Without a DS record, DNSSEC is effectively half-deployed — the zone is signed but no resolver can validate it.

dig isidoregroup.com DS +short

If the DS record is missing while DNSKEY is present, the registrar hasn’t published the delegation signing record. That’s a common half-finished state — someone enabled signing in the DNS host but didn’t push the DS record back to the registrar.

When to recommend DNSSEC to a client

Generally, don’t lead with it. It’s not where the high-impact security work lives. The conversation makes sense in three contexts:

• Regulated client (banking, government, large healthcare) whose compliance posture benefits from defense in depth at the DNS layer.
• A client who already runs a mature DNS environment with a competent admin, where the operational risk is manageable.
• A client whose registrar makes it one-click (some do — Cloudflare and Route53 can both enable DNSSEC with minimal operator action).

For everyone else, surface the Cathedra info result as “DNSSEC is not enabled — this is the norm for SMB and is not a finding we’d act on today.”

Cheat sheet

Condition	Cathedra status	Severity
DNSKEY record present	pass	—
No DNSKEY detected	info	—

What you should remember

• DNSSEC adds cryptographic signatures to DNS responses. Validating resolvers can detect tampering on the wire.
• Cathedra probes via DNS_ANY for a DNSKEY record. The check is informational only — info when missing, pass when present.
• The finding when present: “DNSKEY record detected. DNSSEC appears to be enabled for this domain.”
• A no DNSKEY result doesn’t definitively prove DNSSEC is missing — some servers refuse ANY queries. Confirm with a direct dig {domain} DNSKEY if it matters.
• DNSSEC is rare in SMB MSP work. Recommend it for regulated clients or registrars that make it one-click — not as a default action.

Next lesson closes Module 1 with MX TTL sanity — the smallest check in DnsHygieneCheck, but the one that comes up most often around migrations.

---

Cathedra alignment: DnsHygieneCheck — DNSSEC (DNSKEY probe)