DNSSEC validation is the process by which a DNS resolver checks that the received DNS response actually originates from the domain’s zone and has not been altered en route. This verification is not carried out by the browser or the computer, but by the recursive resolver used by the machine (for example, that of the internet service provider or a public resolver).

DNSSEC records

In addition to the standard DNS records, a few new record types appear in the signed zone:

• DNSKEY: the zone’s public keys. There are usually two: the key-signing key (KSK), which signs the keys, and the zone-signing key (ZSK), which signs the other records.
• RRSIG: the signature. Each record group (for example, all A records for a domain) has one, along with a validity period.
• DS (Delegation Signer): the fingerprint of the domain’s delegation signer key, which appears not in the domain’s own zone but in the parent zone, i.e. the TLD zone. This is submitted to the registry by the registrar.
• NSEC or NSEC3: these are used to confirm, in a signed manner, that a searched-for name or record does not exist.

The chain of trust

The resolver trusts a single certificate in advance: the root zone certificate (trust anchor), which is built into the resolver software. From there, it proceeds step by step downwards:

1. The signed DS record in the root zone validates the key for the TLD (for example, .hu).
2. A DS record located in the TLD’s zone and signed with the TLD’s key verifies the domain’s (e.g. pelda.hu) key signing key.
3. The domain’s key signs the DNSKEY records, thereby authenticating the zone’s signing key.
4. The zone signature (RRSIG) verifies the requested record, such as a domain’s A or MX record.

If any link in the chain is missing or does not match, authentication will fail.

Possible authentication results

• Secure: the chain is error-free from the root to the record. The resolver sets the ad (authenticated data) flag in the response header.
• Unsecured: the domain has no DS record, meaning it does not use DNSSEC. The resolver forwards the response without authentication; the domain functions in exactly the same way as it would without DNSSEC.
• Invalid (bogus): there is a DS record, but the signature is invalid, has expired or does not match. The resolver does not pass on the response but returns a SERVFAIL error; the domain is therefore inaccessible via that resolver.

The zone administrator generates the signatures in advance when modifying records, not on every query. This is why the zone must be re-signed regularly: if the signatures expire, the zone becomes invalid. Typical errors are summarised in the article on problems caused by DNSSEC.

How can you check this?

• Without using the command line, you can use our free DNSSEC verification tool to view the chain of trust described above: it displays the DNSKEY and DS records and signatures for each zone, from the root to the domain, and indicates at which link in the chain the validation breaks down.
• dig +dnssec pelda.hu A: the response includes both the A record and the RRSIG record, and the header ad appears if the resolver used authenticates.
• dig DS pelda.hu: shows whether there is a DS record in the TLD’s zone.
• delv pelda.hu: the BIND package’s tool carries out the validation itself and indicates whether the response was ‘fully validated’.
• DNSViz (dnsviz.net) illustrates this same chain in a diagram.

What does authentication not do?

DNSSEC verifies the authenticity and integrity of responses, but does not encrypt queries: anyone monitoring network traffic can still see which domains are being queried. DNS over TLS (DoT) and DNS over HTTPS (DoH) are used to encrypt traffic between the resolver and the device; these complement DNSSEC, they do not replace it.