DNSSEC lets a validating resolver check that DNS data was signed by the zone owner and was not changed in transit. It does not encrypt anything, does not help with availability, and a mistake in it can make a zone unreachable. It is integrity for DNS data, nothing more.
What you get
RFC 4033 describes two protections:
- Data origin authentication and integrity. Digital signatures sit on DNS record sets. A validating resolver can confirm who signed them and that they are unmodified.
- Authenticated denial of existence. Signed NSEC records let a resolver verify that a name or record type really does not exist.
What you do not get
- Confidentiality. DNS data stays visible by design. For transport privacy see what DNS over HTTPS hides and what it does not.
- Availability. DNSSEC gives no protection against denial of service. It adds new failure modes: expensive cryptographic work, and misconfigurations that make a zone unreachable for validating resolvers.
- Protection for zone transfers and dynamic updates. These need separate channel security such as TSIG, SIG(0) or IPsec.
- Full protection of delegation data. Glue and NS records at zone cuts in the parent are unsigned.
The chain of trust
A validating resolver starts from a trust anchor, usually the root zone's key obtained through a trusted channel outside DNS. It then follows signed links down to the answer. The typical path is DNSKEY, then DS, then DNSKEY again, repeated as needed.
The record types to know:
- DNSKEY holds a zone's public keys. A key signing key (KSK) signs the DNSKEY set, and a zone signing key (ZSK) signs the other data.
- RRSIG is a signature over a record set, valid only between its inception and expiration times.
- DS lives in the parent zone and holds a hash of the child's DNSKEY, linking the two zones.
- NSEC links each existing name to the next one in order, which proves gaps contain nothing. Because the chain can be walked, it lets an attacker enumerate a zone's names.
If a signature is missing or invalid, the data is marked bogus and validating resolvers refuse to return it. That is the safety feature, and also why expired signatures cause outages. We covered one such case in the .de DNSSEC outage of May 2026.
A practical checklist
- Monitor RRSIG expiry, not just that your zone loads.
- Coordinate DS changes with the registrar whenever you change DNS providers or keys.
- Test with a validating resolver, since non validating ones hide errors.
- Plan key rollovers in advance and rehearse them.
The setup steps are in how to configure DNSSEC.
Where Safeguard fits
Safeguard does not manage this layer of your infrastructure. It scans the dependencies and SBOMs of the software you ship, uses reachability analysis to show which vulnerable code paths are actually used, and can enforce policies and gates in CI. A free scan is at gold.safeguard.sh/scan.
Quick check
Does DNSSEC encrypt DNS queries?
No. RFC 4033 states it does not provide confidentiality.
What happens when a DNSSEC signature expires?
Validating resolvers treat the data as bogus and refuse to return it, so the names can appear to be down.
Sources
Last reviewed: 19 October 2026.
