DNSSEC (DNS Security Extensions)

DNSSEC, specified in RFCs 4033 to 4035, adds digital signatures to DNS. Each signed zone publishes its public keys in DNSKEY records and signs its record sets with RRSIG records; the parent zone publishes a DS record, a hash of the child's key, so trust chains from the root zone (signed since 2010) through the top-level domain down to your domain. NSEC or NSEC3 records give signed proof that a name does not exist. A validating resolver that checks the whole chain marks the answer as authenticated.

Why it matters

Plain DNS answers can be spoofed or altered, which lets an attacker redirect traffic. For HTTPS, certificates still authenticate the server, but several certificate-related mechanisms depend on honest DNS. DANE and its TLSA records are meaningless without DNSSEC, and CAs rely on DNS for CAA lookups and DNS-based domain validation, so a signed zone makes those checks harder to subvert. DNSSEC provides integrity, not confidentiality: queries and answers remain visible in transit. The main operational risk is breaking resolution, for example by switching DNS providers or rotating keys without updating the DS record at the registrar; validating resolvers then return SERVFAIL for the entire domain.

Example

dig +dnssec example.com A     # look for RRSIG records and the "ad" flag
dig +short DS example.com     # the DS record published in the parent zone
delv example.com A            # BIND's validating lookup tool; prints "; fully validated"

Common misconceptions

• DNSSEC encrypts DNS. It only signs data. Encrypting queries is the job of DNS over TLS or DNS over HTTPS.
• DNSSEC replaces HTTPS certificates. Browsers do not use DNSSEC to authenticate web servers; certificates remain necessary.
• Enabling DNSSEC at the DNS host is enough. The chain is complete only once the DS record is published at the registrar. When moving DNS providers, plan the key and DS change, or the domain stops resolving for validating resolvers.