# DNSSEC KSK Emergency Rollover

In my last blogpost I showed how to perform a DNSSEC KSK rollover. I did it quite slowly and carefully. This time I am looking into an emergency rollover of the KSK. That is: What to do if your KSK is compromised and you must replace it IMMEDIATELY.

I am listing the procedures and commands I used to replace the KSK of my delegated subdomain dyn.weberdns.de with BIND. And as you might already suggest it, I am showing DNSViz graphs after every step since it greatly reveals the current DNSKEYs etc.

# DNSSEC KSK Key Rollover

Probably the most crucial part in a DNSSEC environment is the maintenance of the key-signing key, the KSK. You should rollover this key on a regular basis, though not that often as the zone signing keys, the ZSKs. I am doing a KSK rollover every 2 years.

In the following I will describe the two existing methods for a KSK rollover along with a step-by-step guide how I performed such a rollover for my zone “weberdns.de”. Of course again with many graphics from DNSViz (with “redundant edges”) that easily reveal the keys and signatures at a glance.

Note that this blogpost is NOT about the Root Zone KSK Rollover that appears in 2017/2018. It is merely about your OWN zone that is secured via DNSSEC.

# DNSSEC ZSK Key Rollover

One important maintenance requirement for DNSSEC is the key rollover of the zone signing key (ZSK). With this procedure a new public/private key pair is used for signing the resource records, of course without any problems for the end user, i.e., no falsified signatures, etc.

In fact it is really simply to rollover the ZSK with BIND. It is almost one single CLI command to generate a new key with certain time ranges. BIND will use the correct keys at the appropriate time automatically. Here we go:

# F5 SSL Profile: “Single DH use” not working?

In the paper of the Logjam attack, a sentence about the F5 load balancers confused me a bit: “The F5 BIG-IP load balancers and hardware TLS frontends will reuse $g^{b}$ unless the “Single DH” option is checked.” This sounds like “it does NOT use a fresh/ephemeral diffie-hellman key for new connections”. I always believed, that when a cipher suite with EDH/DHE is chosen, the diffie-hellman key exchange always generates a new $b$ for computing $g^{b}$. Hm.

Therefore, I tested this “Single DH use” option on my lab F5 unit, in order to find out whether the same public key (as noted in Wireshark) is used for more than one session.