Looking at all examlpes of DNSSEC, you see that the zone includes not only the DNSKEY , but also a RRSIG of the DNSKEY created with that same DNSKEY? Why is this? Why publish a self-signed RRSIG? What security does it add?

UPDATE: In fact, the RFC specifies this, though it doesn't say why: https://www.rfc-editor.org/rfc/rfc4035#section-2.4 :"the child's apex DNSKEY RRset SHOULD be signed by the corresponding private key"

2 Answers 2


The RRSIG record is the proof that a certain RRset was published by the holder of a certain key.

When the parent entity publishes a DS record in the parent zone it is basically saying "we have received proof that the entity to which we have done this delegation is also in possession of the key with the hash that we published in our DS record" (kind of a recursive statement but I hope you get it).

This hash must match the DNSKEY found in the child zone for DNSSEC to validate. One might say that a match at this stage would be proof enough that the delegation is valid. But by signing the actual DNSKEY RRset you can also be sure that the data within the DNSKEY response is actually coming from the holder of the key matching the DS record.

Without the signature the DNSKEY data could actually be malicious. I can't really come up with a attack at this point but better to be safe than sorry I guess?

  • "Without the signature the DNSKEY data could actually be malicious. I can't really come up with a attack at this point" > The attack is trivial: just add your own key to the DNSKEY RRset and then sign malicious records with it. This will work even if the evil key does not match any DS record. See my full answer for details. Commented Sep 19, 2021 at 17:30

In addition to RFC 4035 section 2.4 that you cited, there is also section 5 which imposes a strong (MUST) requirement for validators to validate that the DNSKEY is signed:

the resolver MUST [...] verify that there is some RRSIG RR that covers the apex DNSKEY RRset, and that the combination of the RRSIG RR and the initial DNSKEY RR authenticates the DNSKEY RRset

To actually answer your question, section 5.2 is most relevant:

Given a DS RR for a delegation, the child zone's apex DNSKEY RRset can be authenticated if all of the following hold: the private key [of the matching DNSKEY RR in the child zone] has signed the child zone's apex DNSKEY RRset, and the resulting RRSIG RR authenticates the child zone's apex DNSKEY RRset

What's important to remember here is that the parent DS RRset doesn't have to provide records for every public key in the child DNSKEY RRset. You can have a DNSKEY RRset that contains, say, 4 keys, but the parent zone only has DS records for 2 of these 4 keys. The 2 DNSKEYs that have corresponding DS records in the parent are the Key-Signing Keys or KSKs (by definition). The remaining 2 keys are typically used to sign the rest of the zone (otherwise they would be useless) and thus are called Zone-Signing Keys or ZSKs.

Now, as the above RFC excerpts indicate, in the case of the DNSKEY RRset, the only signatures (RRSIG) that matter are the ones that correspond to keys that have corresponding DS records in the parent. In other words: you don't have to sign the DNSKEY RRset with the ZSKs. As you rightly point out in your question, that is indeed pointless, doesn't provide any additional security, and only adds bloat to DNS responses. (Sadly that doesn't prevent some server software from signing DNSKEYs with ZSKs anyway. In bind9 that can be disabled with dnssec-dnskey-kskonly yes; or dnssec-signzone -x. It would be nice if that was the default…)

However, the above RFC excerpts also state that the DNSKEY RRset must be signed with the KSK. This is actually quite fundamental - if this requirement wasn't there, DNSSEC could be trivially broken by an attacker. The reason for this is simple and can be found in section 5.3.1:

A security-aware resolver can use an RRSIG RR to authenticate an RRset if: [...] the matching DNSKEY RR MUST be present in the zone's apex DNSKEY RRset

In other words, any record in the zone (except DNSKEY) can be authenticated using any DNSKEY record. Even if that particular DNSKEY record is not authenticated by a DS record in the parent zone. And indeed this is precisely what ZSKs are: DNSKEYs that don't have a corresponding DS record but are used to sign RRs anyway. These rules are precisely what makes it possible to have separate KSKs and ZSKs.

Now, since these particular ZSK DNSKEYs are not authenticated through DS records, we need another way to authenticate them. This is why the DNSKEY RRset (i.e. the set of all DNSKEYs) is signed with the KSKs, thus finally answering your question.

If you're still not convinced, imagine a world in which the DNSKEY RRset didn't have to be signed with a KSK. As an attacker, all I'd have to do to break DNSSEC in a man-in-the-middle attack is to generate my own ZSK, inject it into the DNSKEY RRset, and then alter records to my heart's content, taking care to sign them (RRSIG) with my evil ZSK. Obviously this would be quite problematic.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .