What does a DNSSEC RRSIG record returned alongside an answer prove about that answer, and what does it leave unprotected?
answer
- origin and integrity, not secrecy
- one RRset per signature
- a window, not a timestamp of freshness
- the key still needs vouching for
basics
~20 sA DNSSEC RRSIG proves one RRset was signed with the private key behind a zone's DNSKEY and is unchanged, within its inception-to-expiration window. It adds no secrecy, no freshness inside that window and no DoS protection.
solid answer
~50 sAn `RRSIG` carries a digital signature over one **RRset** — every record sharing an owner name, class and type — plus the RRSIG's own fields. If it verifies against a `DNSKEY` in the zone named by the signer's name field, the resolver knows the data came from whoever holds that zone's private key and was not altered in transit or in a cache. What it does not give: confidentiality (RFC 4033 §4 says DNSSEC is not designed to provide it), protection against denial of service, or proof that this is the *latest* version of the data — a captured answer replays successfully until its expiration time. Nor does it prove a name is absent (that is the job of NSEC or NSEC3), and it is only meaningful once the key itself is authenticated, through a DS chain or a configured trust anchor.
go deeper
Recall the two words: origin and integrity. DNSSEC signs data so a resolver can tell it is genuine and unchanged; it does not hide anything.
Explain that the unit of signing is the RRset and that the signature has an inception and an expiration time, and say why the key must be authenticated separately.
Show you know the limits an operator lives with: replay inside the validity window, no denial-of-service protection, and absence proved by different records entirely.
Frame the trade-off: longer validity windows ease signing operations but widen the replay window, so window length is a security decision, not just an operational convenience.
## What an RRSIG record is DNSSEC (RFC 4033-4035, named together as BCP 237 by RFC 9364) adds **data origin authentication** and **data integrity** to DNS. It does that with public-key signatures stored in a resource record of type `RRSIG` (type value 46, RFC 4034 §3). A signed zone carries, for every authoritative RRset, at least one RRSIG at the same owner name (RFC 4035 §2.2). Two terms matter: - **RRset** — all records with the same owner name, class and type, for example every `A` record at `www.example.net`. DNSSEC signs RRsets, never single records. - **Validity window** — the RRSIG's `Signature Inception` and `Signature Expiration` fields. Outside that window the signature MUST NOT be used (RFC 4034 §3.1.5). ## What a verified RRSIG proves The signature covers the RRSIG's own RDATA (minus the signature) followed by the RRset in canonical form (RFC 4034 §3.1.8.1). When a resolver verifies it with the matching public key, it learns: 1. **Origin** — the RRset was signed with the private key that pairs with a `DNSKEY` in the zone named in the `Signer's Name` field. 2. **Integrity** — no record in the RRset was added, removed or edited after signing; changing any byte breaks the signature. 3. **The parameters were signed too** — the type covered, algorithm, labels count, original TTL and the validity window are inside the signed data, so they cannot be altered without detection either. ## What it leaves unprotected | Property | Provided by an RRSIG? | Where it comes from instead | |---|---|---| | Confidentiality of queries and answers | No — RFC 4033 §4 | Encrypted DNS transports | | Protection against denial of service | No — RFC 4033 §4 | Rate limits and capacity | | Proof that the answer is the newest version | Only bounded by the expiration time | Short validity periods | | Proof that a name or type does not exist | No | NSEC or NSEC3 records | | Trust in the signing key itself | No | A DS record in the parent and the chain above it | | Protection of zone transfers and dynamic updates | No — RFC 4033 §4 | Transaction-level message authentication | The **replay** row is the one candidates miss. An RRSIG says "this was true when signed", not "this is true now". If an operator changes an address but the old signed RRset is still inside its validity window, an attacker who captured it can serve it and it will validate. RFC 6781 treats the signature validity period as the bound on that risk, which is why it recommends short windows where the data changes or a key may be compromised. The **key** row matters just as much. A signature only proves which key signed the data. If anyone could publish any `DNSKEY` and have it believed, an attacker would simply sign forged data with a key of their own. Unless it is itself a configured trust anchor, the key is trusted only because a `DS` record in the parent zone vouches for it, and the parent's key is vouched for in turn, up to a trust anchor. ## Why the RRset, not the record Because the unit is the RRset, a validator cannot accept two of three `A` records and reject the third: either the whole set verifies or none of it does. An RRset may carry several RRSIGs (one per signing key or algorithm), and an RRSIG itself is never signed, since that would loop forever (RFC 4035 §2.2). ## What to say in an interview - DNSSEC answers "is this the data the zone owner published?", not "can anyone see it?". - The signature is time-bounded, so freshness is only as good as the expiration time. - A signature without an authenticated key proves nothing; the DS chain is what makes it count.
- Can an attacker replay a captured, validly signed DNSSEC answer after the zone owner changes the record?Yes, until the RRSIG's expiration time passes. The signature proves the data was signed, not that it is current, and nothing in the record tells a validator the zone has since changed. RFC 6781 treats the signature validity period as the limit on this replay risk, which is one reason volatile data gets shorter windows.
- Does one RRSIG cover a single A record or every A record at a name?Every A record at that name: the signature covers the whole RRset of one owner name, class and type in canonical order. You cannot sign or validate one record of the set on its own. An RRset can carry more than one RRSIG, for instance one per key during a key change.
saying these in an interview costs you the question
- DNSSEC encrypts DNS answers so on-path observers cannot read them.
- An RRSIG signs the whole DNS response message, header flags included.
- A valid RRSIG proves the record is the latest version in the zone.
- Each individual record in a signed zone gets its own separate RRSIG.
- A verified signature is enough on its own; the key needs no further vouching.