1. What Problem DNSSEC Solves¶

Classic DNS has no authentication. A resolver asking "what's the address for example.com?" has no cryptographic way to confirm the answer it gets back actually came from example.com's real authoritative servers unmodified — it just trusts whatever arrives on the wire matching the query's transaction ID and source port. This is what makes cache poisoning and on-path response forgery possible (see the dedicated DNS-attacks guide for the attack side of this).

DNSSEC (DNS Security Extensions) adds digital signatures to DNS records, so a validating resolver can cryptographically verify that an answer is authentic and unmodified, and — just as importantly — that a negative answer (a name genuinely doesn't exist) is also authentic rather than an attacker's forged NXDOMAIN suppressing a real record. It is explicitly not encryption — DNSSEC-signed responses are just as visible in plaintext on the wire as unsigned ones; it provides authenticity and integrity, not confidentiality (that's DoT/DoH's job, covered in the Unbound and general DNS guides).

2. The New Record Types¶

3. Key Signing Keys vs. Zone Signing Keys¶

Nearly every real deployment uses two key pairs rather than one, for both security and operational reasons:

• Zone Signing Key (ZSK) — signs the actual record data (RRSIGs over A, MX, TXT, etc. records). Rotated relatively often (weeks to months) since it's used constantly and a compromise only needs to be survivable, not catastrophic.
• Key Signing Key (KSK) — signs only the DNSKEY record set itself (i.e., it signs the ZSK, not the zone data directly). Rotated much less often, because rotating it requires updating the DS record at the parent zone — an external, often manual or slower-moving operation — whereas ZSK rotation is entirely internal to the zone and can be automated freely.

This split means routine key hygiene (ZSK rotation) never requires touching anything outside your own zone, while the rarer, higher-friction operation (KSK rotation, requiring parent coordination) is minimized.

4. The Chain of Trust¶

Validation works by walking a chain from an inherently trusted starting point down to the record being requested:

Trust anchor (root's DNSKEY, distributed out-of-band)
        │  validates
        ▼
Root zone's RRSIG over its own DNSKEY set
        │  root also holds a DS record for .com, signed
        ▼
.com zone's DNSKEY, verified against that DS hash
        │  .com holds a DS record for example.com, signed
        ▼
example.com's DNSKEY, verified against that DS hash
        │  signs
        ▼
example.com's actual A/MX/TXT/etc. records (via RRSIG)

Each parent zone vouches for its child by holding a DS record — a hash of the child's DNSKEY — and signing that DS record with its own key. A resolver only needs to unconditionally trust one thing: the root zone's key (the trust anchor), distributed out-of-band (built into resolver software, refreshed via RFC 5011 automated rollover — see the Unbound guide, §10, for the practical mechanics of this). Every other link in the chain is verified cryptographically rather than trusted by assertion.

A break anywhere in this chain — a missing DS at the parent, an expired RRSIG, a KSK rotated without updating the parent's DS — causes validation to fail for that zone and everything below it, which is why DNSSEC misconfigurations tend to be all-or-nothing outages rather than partial degradations.

5. Proving Non-Existence: NSEC and NSEC3¶

Signing "this record exists, here's its data" is straightforward — sign the record. Signing "this record does not exist" is harder, since there's no record to attach a signature to. DNSSEC solves this by having the zone assert, and sign, an ordering claim:

• NSEC lists, for each real name in the zone, what the next name in canonical sort order is. A query for a name falling alphabetically between two consecutive NSEC-linked names proves no name exists there — but as a side effect, walking every NSEC record front-to-back enumerates the entire zone's contents, a privacy/reconnaissance concern for zones that don't want their full namespace trivially listable.
• NSEC3 solves the enumeration problem by hashing owner names before establishing the "next name" ordering — the proof-of-nonexistence property is preserved, but an attacker walking the chain gets a list of hashes, not actual names, meaningfully raising the cost of zone enumeration (though not eliminating it entirely — NSEC3 hashes can still be attacked with brute-force/rainbow-table techniques against common name patterns, and NSEC3 with opt-out or NSEC3 white lies (minimally-covering NSEC3, "Black Lies") exist as further-hardened variants some providers use).

6. Signing a Zone (BIND Example)¶

# Generate a KSK and ZSK
dnssec-keygen -a ECDSAP256SHA256 -f KSK example.com
dnssec-keygen -a ECDSAP256SHA256 example.com

# Sign the zone (BIND's automated inline-signing is the modern approach)

Modern BIND (dnssec-policy in named.conf, available since BIND 9.16) automates key generation, rotation, and re-signing entirely — the older manual dnssec-keygen + dnssec-signzone workflow is still valid but increasingly considered legacy for anything beyond learning the mechanics:

dnssec-policy "default-like" {
    keys {
        ksk lifetime unlimited algorithm ecdsap256sha256;
        zsk lifetime P30D algorithm ecdsap256sha256;
    };
};

zone "example.com" {
    type primary;
    file "/etc/bind/db.example.com";
    dnssec-policy "default-like";
};

With dnssec-policy in place, BIND generates keys, signs the zone, re-signs before RRSIGs expire, and rotates ZSKs on the given lifetime automatically — the operational burden that made hand-rolled DNSSEC deployments notoriously error-prone in BIND's earlier years is largely gone in current versions.

7. Publishing the DS Record¶

Signing a zone yourself doesn't make it validated by the world — the chain of trust requires the parent zone (typically via your registrar) to publish a DS record pointing at your KSK. This is usually a registrar-portal step: after signing, dnssec-dsfromkey (or the equivalent output from dnssec-policy's key files) produces the DS record's exact content, which then gets pasted into the registrar's DNSSEC configuration page for the domain. Until that DS record is live at the parent, your zone is signed but not yet validated by the outside world — a state sometimes called "islands of security," where your own signatures are internally consistent but nothing above you in the tree vouches for them.

8. Common Failure Modes¶

dig +dnssec +multi example.com and online checkers (e.g. Verisign's DNSSEC debugger) are the standard first diagnostic steps — they show the actual RRSIG validity windows and whether the chain resolves cleanly.

9. What DNSSEC Does Not Protect Against¶

Worth being precise about the boundary, since it's commonly overstated: - Not confidentiality — a DNSSEC-signed query/response is fully readable in transit; pair with DoT/DoH for privacy. - Not protection against a compromised authoritative server — if an attacker gets access to the actual signing infrastructure and private keys, they can sign whatever forged records they like; DNSSEC proves data came from whoever holds the zone's keys, not that the zone operator itself is trustworthy or uncompromised. - Not a defense against DDoS/amplification — if anything, DNSSEC responses are larger (carrying RRSIGs/DNSKEYs), which somewhat increases amplification potential for reflection attacks unless mitigated separately (response-size limiting, rate limiting). - Not universally deployed — adoption is meaningfully partial; many zones remain unsigned, and many resolvers validate permissively (allow-downgrade-style behavior, per the systemd-resolved guide) specifically because strict enforcement still breaks against real-world unsigned/misconfigured zones often enough to be impractical as a hard default everywhere.

10. Reference Links¶

• RFC 4033/4034/4035 — the core DNSSEC specification set
• ISC's BIND DNSSEC guide: https://bind9.readthedocs.io/en/latest/dnssec-guide.html
• Verisign DNSSEC debugger: https://dnssec-debugger.verisignlabs.com/
• ICANN DNSSEC resources: https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en