Validating DNSSEC Signatures: What RRSIG and DNSKEY Records Must Show

If DNSSEC signing is the act of producing signatures, validation is the act of checking them, and the two halves must agree exactly. A zone owner signs each set of records with a private key and publishes the signature in an RRSIG record alongside the records it covers. A resolver fetches the records, the signature, and the public key from a DNSKEY record, and checks that the signature matches the records and the key, and that the signature is still within its validity window. If any part of that check fails, the resolver treats the answer as bogus rather than merely uncertain, which is a stronger response than ordinary DNS gives for a missing record.

The DNSSEC Validator takes RRSIG or DNSKEY records you paste in and validates that their expected fields are present. An RRSIG record carries the type of record it covers, the algorithm, the number of labels in the owner name, the original time-to-live, the signature expiration and inception times, the key tag, the signer's name, and the signature itself. Each field has a job: the covered type says what was signed, the label count prevents a signature from being replayed under a different name, the original TTL fixes the value that was signed, and the expiration and inception times bound the window in which the signature may be trusted. A missing field is not a minor omission; it is a record a resolver cannot use.

The validity window deserves particular attention, because it is where time itself becomes a security control. Signatures are typically valid for days or weeks, and a zone must be re-signed before the oldest signature expires, otherwise the zone stops validating even though nothing was attacked and nothing was misconfigured. Clock accuracy matters on both sides: a resolver with a wildly wrong clock may reject signatures that are perfectly valid, and a signer with a wrong clock may produce signatures whose window does not cover the present. Time, in DNSSEC, is not a detail; it is part of the signature.

Worked example

Worked example with sample values. Suppose you paste a sample RRSIG record covering type A, with algorithm 13, labels 2, original TTL 3600, expiration 20270601000000, inception 20270501000000, key tag 12345, signer example.com, and a base64 signature. Subtracting the inception date from the expiration date gives a window of 31 days, since May has 31 days, and dividing the original TTL of 3600 by 3600 gives 1 hour, which is the TTL value that was signed and must match the record set it covers. Counting the fields before the signature gives 8, and each one is present in the sample, so the record passes a field-presence check. The sample dates are illustrative only, written to show how the window is read, not signatures copied from a live zone.

Now suppose the expiration is moved a month earlier, so that the window ends before today. Every field is still present and well formed, yet the signature is expired and a validating resolver must reject it. Suppose instead the key tag is changed from 12345 to 12346 while the DNSKEY record still carries 12345; the fields are all present, but the signature now points at a key that does not match it, and validation fails. Both cases show the same lesson: presence is the first check, agreement is the second, and a validator that only checks presence can never be the final word on whether a zone validates.

Mistakes to avoid

The first mistake is assuming that a complete RRSIG record means a valid zone. Field presence and signature correctness are different checks, and only a cryptographic verification against the actual records and key can confirm the latter. The second mistake is letting signatures expire by forgetting the re-signing schedule, which turns a healthy zone bogus on a predictable date. The third mistake is changing a record set, for example an address, without re-signing it, which leaves a signature over data that no longer exists. The fourth mistake is pasting signature material into a public checker without considering what it reveals; signatures themselves are public by design, since resolvers fetch them, but private keys must never be pasted anywhere, and the two must not be confused.

Another trap is blaming the resolver when validation fails. A resolver that rejects a bogus answer is doing its job, and disabling validation to restore service trades away the protection DNSSEC exists to provide. The correct response is to find the broken link, whether it is an expired signature, a mismatched key tag, or a stale parent record, fix it at its source, and let validation succeed on its own terms.

Putting it into practice

Use the validator when auditing a zone before a launch, after a re-signing, and when a validation failure needs to be narrowed down to a missing or malformed field. Paste the RRSIG and DNSKEY records, read the covered type, key tag, signer name and validity window in order, and compare them against the records they are meant to cover. Keep a re-signing calendar, watch the earliest expiration in the zone, and re-check after every signing event. Signatures are promises with expiry dates, and a routine that watches those dates is what keeps a signed zone trustworthy rather than merely signed.

Related tools and reading: the DNSSEC Checker, the DNS Lookup cover neighbouring checks that pair naturally with this one, and the guide at [/blog/cname-lookup-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

  • RRSIG covers a record set, with a key tag and a validity window
  • Label count and original TTL are part of what was signed
  • An expired signature fails even when every field is present
  • Presence checks never replace cryptographic verification

In short: Validation checks that a signature matches its records, its key and its window. The validator reads pasted RRSIG or DNSKEY records. Missing fields, expired windows and mismatched key tags all fail. Presence is the first check, not the final word.

One habit ties all of this together: re-check after every change. A result from the DNSSEC Validator is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.