DNSSEC

Stands for: Domain Name System Security Extensions

Extensions that add origin authentication and integrity to DNS data, with signatures a validating resolver can check.

A validating resolver uses it to tell a genuine answer from a forged or altered one, following a chain of trust from a configured trust anchor, normally the root key, down through each signed delegation. RFC 9364 (2023) named it Best Current Practice 237.

The core is RFC 4033, 4034 and 4035 (March 2005), the third design after RFC 2065 and RFC 2535, with RFC 6840 since added as an omnibus update. It brings four record types, RRSIG for signatures, DNSKEY for zone keys, DS in the parent to vouch for a child's key and NSEC to prove that a name or type does not exist, plus the AD and CD header bits and the DO bit in EDNS. The signing key belongs to the zone, not to the servers that publish it.

A resolver starts from at least one trust anchor and builds the chain DNSKEY, then DS and DNSKEY for each delegation, down to the RRset. An answer is secure, insecure (signed proof that a delegation has no DS), bogus or indeterminate. When validation fails on a recursive query the server must return SERVFAIL, and only a query with CD set gets the data anyway, so a SERVFAIL that turns into an answer with dig +cd points at a signing fault.

It gives no confidentiality and no protection against denial of service: queries and answers stay readable. RFC 9364 notes that no Standards Track RFC offers another method of origin authentication, and records how far deployment lags: by recent estimates, fewer than 10% of the domain names used for websites are signed and only around a third of queries to recursive resolvers are validated.

Also known as: dnssec

Sources

← All glossary entries