RRSIG Lookup
DNSSEC resource-record signatures.
Enter a value above to run RRSIG Lookup
e.g. cloudflare.com
Quick answer
RRSIG Lookup shows the DNSSEC signatures that cryptographically sign a domain's records, so resolvers can verify the answers weren't tampered with. Each RRSIG lists the record type it covers, the signing algorithm, the key tag, and the signature's start and expiry dates; an expired or missing RRSIG means DNSSEC validation will fail.
RRSIG Lookup fetches the DNSSEC signature records that a signed zone attaches to its data. Every RRset in a DNSSEC-signed zone is covered by one or more RRSIG records, each proving that the answer came from the real zone and was not tampered with in transit. This tool queries a name and record type, then shows the RRSIG covering that RRset so you can inspect the signing algorithm, the key tag, and the signature's validity window. It is useful when validating resolvers report SERVFAIL and you need to see whether the signatures are actually present and current.
How it works
The tool asks an authoritative or validating server for a specific type (say A or MX) with DNSSEC data requested. Alongside the answer it returns the RRSIG that covers that exact RRset. An RRSIG names the type it covers, the algorithm and key tag of the ZSK or KSK that produced it, the signer's zone, the original TTL, and inception and expiration timestamps. The signature itself is the cryptographic value a resolver checks against the matching DNSKEY.
How to read the results
Read the type-covered field first: it must match the record you queried. Check the key tag and algorithm number against the zone's DNSKEY set so you know which key signed it. The important fields are the inception and expiration dates, shown in UTC. Expiration must be in the future; inception must already have passed. The signer name should equal the zone apex. If any of these look wrong, validation downstream will fail even though the record data itself is fine.
Common problems & fixes
Expired RRSIGs are the classic failure: signatures have a lifetime, and a broken re-signing job leaves stale ones behind, causing SERVFAIL on validators. Regenerate them by re-signing the zone. A missing RRSIG on a record that should be signed means the zone was not re-signed after an edit. A key-tag or algorithm mismatch against the DNSKEY points to a rollover that was only half-completed. Confirm your DS record at the parent still matches the active KSK.
Frequently asked questions
- Why is there more than one RRSIG on some records?
- During a key rollover a zone temporarily signs the same RRset with the old and new keys, producing two RRSIGs with different key tags. Resolvers only need one to validate. You may also see multiple algorithms when a zone supports more than one, since every algorithm in the DNSKEY set must sign each RRset.
- What do the inception and expiration dates mean?
- They define the window in which the signature is considered valid. A validating resolver rejects an RRSIG whose current time is before inception or after expiration, returning SERVFAIL. Zones usually set inception slightly in the past to tolerate clock skew and re-sign well before expiry, so signatures never lapse in normal operation.
- An RRSIG exists but validation still fails. Why?
- The signature may be present but not verifiable. Check that the RRSIG's key tag matches a DNSKEY in the zone, that the DNSKEY is vouched for by a DS record at the parent, and that timestamps are current. A single altered byte, a broken chain of trust, or a stale DS after a KSK rollover all produce a valid-looking RRSIG that no resolver accepts.