Until now I understood the following about DNSSEC:

  1. A client requests a certain Domain let's say google.se
  2. The root server sends the client his public KSK and public ZSK signed by his private KSK so the client can verify the DNS root server by checking the signature using the public KSK which he knows
  3. Then the DNS root server sends the client the name and address of the se DNS server. Additionally he sends the client a hash of the name and the public KSK of the se DNS server signed by the root DNS server's private ZSK

Why does a ZSK exist at all? Could they not use only the KSK?

How does the client receive the public KSK of the se DNS server if he retrieves it only hashed?

1 Answer 1


You can only use one key to sign the data…

… However, it's way more convenient to use 2 pairs of key (ZSK & KSK). There are 2 important points to take into account:

  • You need to regularly refresh the key (ZSK) used to sign the records. (For security reasons.)
  • You need to be sure that the DS record in the parent zone corresponds to the key used in the aforementioned zone.

This is very important, any error in the key rollover process would result in a total failure. And each time you would renew your ZSK, you would need to update the parent zone. This is why a KSK is used. This key will only be used to sign the ZSK (and itself). The DS record in the parent zone should correspond to that KSK. You don't need to renew the KSK as often as the ZSK.

The cool thing is that, with these 2 keys, you can renew the ZSK without updating the parent zone! To summarise briefly, you need to:

  • Sign the records with the new ZSK.
  • Sign the new ZSK with the current KSK.

As long as you don't change the KSK, you don't have to change the DS record in the parent zone.

The KSK of the .se zone is sent by the .se nameservers. The hash is sent by the parent zone, the root's nameserver in that case.

Here's briefly how DNSSEC works:

  1. The resolver gets a record, along with its signature (RRSIG) signed with the zone's ZSK.
    To allow the resolver to check that signature, it also gets the ZSK, and its signature (RRSIG) signed with the KSK.
    To allow the resolver to check that signature, it also gets the KSK, and its signature (RRSIG) signed with the KSK. (self-signed)

You can see that, if you trust the algorithms used, everything is as secure as the KSK is. But the KSK is sent by the same nameserver that sent you the record! It could seem pretty useless, but not really…

  1. The resolver gets from the parent zone the DS record for the aforementioned zone. This DS records is a digest of the aforementioned zone KSK.

As you can see, as long as you trust the parent zone, you can trust the KSK used, and thus the record.

That's how DNSSEC works: that DS record is also signed by the parent zone ZSK, like the record was in the child zone. You check it with the ZSK, the KSK, and the DS record of the parent of the parent zone. And so on and so forth until you reach the root zone. The root's KSK are hardcoded in the resolver.

Note: the key rollover process is slightly more complicated. Because of resolvers caching data, you might need to keep old records (signatures) for a time.

  • 1
    Thanks. I think a problem I still had/have is the difference between signature and encryption since they appear so similar to me. This also created a misunderstanding in my thoughts about DNSSEC since only signatures are used and no encryption.
    – Chris
    Jul 1, 2016 at 16:28
  • "You can only use one key to sign the data…" RRSIG records contain the key ID used to generate them, so you can totally have different signatures with different keys, and it happens during key rollovers. Jul 31, 2022 at 17:37

You must log in to answer this question.

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