DNSSEC – Root Zone KSK Rollover (11th of October)
In just one week from now it will be the first time that the DNS Root Zone Key Signing Key (KSK) will be rolled over and replaced with a new key. This long planed procedure was actually planed one year ago, but postponed because of data that suggested that a significant number of resolvers where not ready for the rollover. Now it is planed for the 11th of October 2018.
Currently the root zone is still signed by the old KSK with the ID 19036 also called KSK-2010. The new KSK with the ID 20326 was published in the DNS in July 2017 and is called KSK-2017. The KSK-2010 is currently used to sign itself, to sign the Root Zone Signing Key (ZSK) and to sign the new KSK-2017. The relationship between those keys can be evaluated over the website dnsviz.net. Keep in mind, the rollover only affects the KSK. The ZSK gets updated and replaced more frequently without the need to update the trust anchor inside the resolver.
It is also possible to check the current status with the
dig command and get the key details of the KSK-2010 and KSK-2017, but also for the available ZSKs.
#> dig +multiline DNSKEY . ;; ANSWER SECTION: . 3416 IN DNSKEY 257 3 8 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ ... LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ) ; KSK; alg = RSASHA256 ; key id = 19036 . 3416 IN DNSKEY 257 3 8 ( AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO ... 9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ) ; KSK; alg = RSASHA256 ; key id = 20326 . 3416 IN DNSKEY 256 3 8 ( AwEAAdp440E6Mz7c+Vl4sPd0lTv2Qnc85dTW64j0RDD7 ... ogfk8hPipf7TTKHIi20LWen5RCsvYsQBkYGpF78= ) ; ZSK; alg = RSASHA256 ; key id = 2134 . 3416 IN DNSKEY 256 3 8 ( AwEAAfaifSqh+9ItxYRCwuiY0FY2NkaEwd/zmyVvakix ... inBEzWwW9GpnY+ZmBWgZiRVTaDuemCTJ5ZJWLRs= ) ; ZSK; alg = RSASHA256 ; key id = 41656
If you extend this command with the
+dnssec switch, you will see in addition the RRSIG signature response that is currently signed with the KSK-2010 key with the ID 19036.
#> dig +dnssec +multiline DNSKEY . . 9561 IN RRSIG DNSKEY 8 0 172800 ( 20181022000000 20181001000000 19036 . LT/Gof2lit8FK1XVBHqPAc+OlHsqVgvbmHrgXw6ArAPQ ... vPvuoQLIYrDZ76I32RmuvMnVB7j+fzefaQ== )
The KSK rollover is simply switching the signing between the KSK-2010 to the KSK-2017. This is frequently done with the ZSKs, but the first time with the KSK trust anchor.
The ICANN published a short video explaining the KSK rollover in quick detail.
Check your SUSE systems
The first question you have to ask yourself is: “Are you using a DNSSEC enabled resolver?”
The following quick test gives only a result back if your resolver does not support DNSSEC validation. In case you have a working DNSSEC resolver the command will bring no result back.
#> dig +short +dnssec A dnssec-failed.org 220.127.116.11 A 5 2 7200 20181009172415 20181002141915 44973 dnssec-failed.org. 5VrteEs0ZfrmzuOExqLmC1brUWzUe9mBSrASFDZiVySaQHutGraOOnx1 0PWM+fcZQtROS8NBLovL/7M/M8jUfylkYwt9MIsoTRsJNgtEyI4tlU8U jfwgnGMKAdJMZHyPcXtdLsVnpZBV2GRE18dR1kWsaZ61WdUC/Q153ga5 HS8=
So again, if you see an IP address as shown above you have nothing to worry about, as you are not using DNSSEC and therefore the KSK rollover will have no affect on your resolver.
In case you are using a DNSSEC enabled resolver, there is also nothing to worry about. SUSE and openSUSE published the new KSK during a regular maintenance update. Every SUSE and openSUSE system that is on an up-to-date patch level will have the new KSK already installed.
First of all both KSKs (2010/2017) are included inside the
named binary. So there is no real need for a configuration file. However, when the file
/etc/bind.keys exists bind will overwrite its internal configuration. The
bind.keys file comes from the
If your SUSE/openSUSE system has a bind version >= then the listed versions below, then the key is already on your system.
SUSE Linux Enterprise 12 SP3: bind-utils-9.9.9P1-63.7.1 SUSE Linux Enterprise 11 SP4: bind-9.9.6P1-0.51.7.1 openSUSE Leap 43.2: bind-9.9.9P1-53.1.x86_64 openSUSE Leap 15.0: bind-9.11.2-lp150.7.2
In case you are running a Long Term Service Pack Support (LTSS) system, you can also simply check the RPM changelog for the following entry.
rpm -q --changelog bind | grep -B1 KSK * Fri Jan 26 2018 email@example.com - Update bind.keys for DNSSEC root KSK rollover (bsc#1047184)
You can also use the
rndc command from the
bind-utils package to check the configured KSKs. Simply configure
rndc as described inside the
rndc-confgen output and you should be able to execute the following command.
#> rndc secroots #> cat /var/lib/named/named.secroots 04-Oct-2018 15:40:38.219 Start view _default ./RSASHA256/20326 ; managed ./RSASHA256/19036 ; managed
dnsmasq package comes with an extra trust anchor configuration file called
/etc/dnsmasq.d/trust-anchors.conf. In comparison to
dnsmasq package does not have a complete copy of the KSKs, instead it uses a Delegation Signer (DS) Resource Record inside the trust anchors file.
# The root DNSSEC trust anchor, valid as at 10/02/2017 # Note that this is a DS record (ie a hash of the root Zone Signing Key) # If was downloaded from https://data.iana.org/root-anchors/root-anchors.xml trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
Flickr picture remarks: Anchored from Keith Hall