What DNSSEC validation is checking
Ordinary DNS helps a resolver find records such as the address associated with a website name. DNSSEC adds a way to check the authenticity and integrity of certain DNS answers. It does not encrypt DNS traffic or establish that a website itself is safe. Its narrower job is to help a validating resolver determine whether an answer matches data signed by the relevant DNS zone.
Two record types are central to that check. A DNSKEY record publishes a public key for a zone. An RRSIG record carries a digital signature over a set of DNS records. The resolver uses the public key to check the signature, but it must also establish that the key is trustworthy. A signature that verifies with an untrusted key is not enough.
DNSKEY: the public key a resolver uses
A DNSKEY record belongs to a DNS zone and contains a public key, along with fields that identify how the key is intended to be used. The corresponding private key is kept by the zone operator and is used to create signatures. The private key is not published in DNS; the public DNSKEY is what resolvers can retrieve.
A zone may publish more than one DNSKEY. Operators often separate keys used to sign ordinary record sets from keys used to sign the DNSKEY set, commonly called zone-signing keys and key-signing keys. These are operational roles, not two different DNSSEC record types. Multiple keys can also appear during a planned key change, so seeing more than one DNSKEY is not automatically a problem.
Publishing a DNSKEY does not, by itself, prove who controls it. An attacker able to substitute both an answer and a key could otherwise present a matching signature. DNSSEC addresses that problem by linking trust from a parent zone to its child zone.
RRSIG: a signature over a record set
DNSSEC signs an RRset: records with the same name, type and class. For example, if a name has multiple A records, the signature covers the A RRset rather than treating each address as an independently signed item. An RRSIG identifies the record type it covers and includes information such as the signing algorithm, a key identifier, and the signature’s validity period.
Suppose a resolver receives an A RRset for www.example.com and an accompanying RRSIG. It obtains an appropriate DNSKEY for the example.com zone and checks the signature against the received RRset. If the records were changed without being signed again by the corresponding private key, that check should fail. The resolver also checks relevant signature details, including whether the signature is within its validity period.
RRSIG records do not guarantee that an answer is useful or that the underlying website is legitimate. They help establish that the signed DNS data has not been altered since it was signed by a key the resolver trusts.
How a key becomes trusted
A validating resolver starts with a configured trust anchor, typically for the DNS root. It can then work down the DNS hierarchy. At a signed delegation, the parent zone publishes a DS record that identifies a child zone’s DNSKEY through a digest. The parent’s signature protects its DS record; a matching DNSKEY in the child zone can then become a trusted basis for checking that child’s signatures.
In simplified form, the resolver checks the parent’s signature, uses the trusted DS record to identify a matching child DNSKEY, validates the child’s DNSKEY set, and uses a trusted child key to validate other signed RRsets. The precise steps depend on the records and keys involved, but the principle is consistent: DNSKEY supplies a verification key, RRSIG supplies the signature, and the chain of trust explains why the key should be accepted.
A delegation without a DS record generally marks the child zone as insecure from DNSSEC’s perspective. That is different from a zone with a DS record whose DNSKEY or signatures fail validation. In the latter case, a validating resolver has evidence that the expected chain is broken.
What failures mean when troubleshooting
If a signature is expired, an expected DNSKEY is missing, or a DS record no longer matches the child’s keys, validation can fail. A validating resolver will generally avoid returning the affected data as an authenticated answer; applications may see a DNS lookup failure, often reported as SERVFAIL. A failure does not automatically mean an attack occurred. Configuration mistakes and poorly coordinated key changes can also break validation.
When diagnosing a DNSSEC issue, check that the parent’s DS record matches a DNSKEY published by the child zone, that the DNSKEY set and requested RRsets have suitable RRSIG records, and that the signatures are within their validity periods. Also check the authoritative answers rather than assuming a website or email service is at fault. DNSSEC can authenticate a signed denial of existence as well, using records such as NSEC or NSEC3, but the same need for trusted keys and valid signatures applies.
