[sf-lug] DNSSEC - 2017-10-11 ROOT KSK KEY ROLLOVER!!!
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Sun Oct 1 12:26:32 PDT 2017
DNSSEC - 2017-10-11 ROOT KSK KEY ROLLOVER!!!
So ... if you're doing at least semi-regular updates of your operating
system, you probably have nothing to be concerned about on this - and
it's probably automagically taken care of for you, without your even
noticing. Even if you're not doing that, your DNS software might still
well take care of that automagically for you.
Also, if you're not using DNSSEC - e.g. explicitly disabled it in
applicable resolver software/configurations, then likewise you've no
need to be concerned about DNS root key rollover (though you may have
other things to be concerned about - such as DNS spoofing and cache
poisoning ... though DNSSEC only "solves" that where DNSSEC is used for
the applicable DNS data).
So ... what's happening, and specificly on 2017-10-11?
Domain Name System Security Extensions (DNSSEC) uses keys to sign DNS
data. The trust works relative to anchor point(s), and flows (is
further delegated) from there. Since 2010-07-15 the root (.) zone has
been signed, and since then, also many (now most) TLDs thereunder, also
signed. And with that, much DNS software, notably also including
resolvers, has started using DNSSEC where available. That's generally a
*good* thing! :-) But keys can be rolled (rotated/changed) - in fact
it's recommended that be done once in a while. And ... 2017-10-11 that
happens for the root zone KSK key. In DNSSEC, there are two main
classes of key types, - Key Signing Key (KSK), and Zone Signing Key
(ZSK). ZSK keys can be - and often regularly are - rolled - and quite
transparently to most users/clients. These are keys used to sign zones,
which are themselves signed by KSK keys. KSK keys are the ones that are
more involved to roll, as they're tracked by a Delegation Signer (DS)
record in DNS in the parent zone ... but ... there is no parent of the
root zone - other than itself. So the trust works a bit differently for
the root zone. Namely, that trust data - notably the public key(s)
(and/or hash(es) thereof) - are distributed to the relevant
software/resolvers. This is how they know to trust the root key. So
... with new KSK for the root, that has to be updated in software
configurations. That data has been made securely available since
2017-02-03, and additionally published in DNS since 2017-07-11. When
the KSK rolls over - presently scheduled for 2017-10-11 - that's when it
all starts to really matter for the key rollover. Note also that much
DNS software may also take care of this automagically. E.g. if the
software is set to use DNSSEC, and additionally use that existing trust
to pull, save, and use newer keys (RFC-5011) - most notably for the root
zone - then it will also automagically handle the root zone KSK key
rollover.
What's the worst that could happen? If your DNS software is using
DNSSEC (generally a good thing!), and it's not been updated nor is it
set to or capable of updating itself on the root KSK key, then once the
root KSK key rolls, any and all DNSSEC not otherwise anchored, would
then subsequently start to fail.
How can you check? Varies greatly, depending upon your DNS resolver
software. A fairly good - but not quite 100% check, is if your resolver
is using DNSSEC and has and trusts the new root KSK key.
Here are some example bits (your resolver/mileage may vary).
Notice this file has been relatively recently updated,
and contains the newer data:
$ dpkg -L bind9 | fgrep keys
/etc/bind/bind.keys
$ ls -l /etc/bind/bind.keys && ls -lc /etc/bind/bind.keys
-rw-r--r-- 1 root root 3923 Aug 28 03:43 /etc/bind/bind.keys
-rw-r--r-- 1 root root 3923 Sep 9 16:21 /etc/bind/bind.keys
$ tail -n 15 /etc/bind/bind.keys
# This key (20326) is to be published in the root zone in 2017.
# Servers which were already using the old key (19036) should
# roll seamlessly to this new one via RFC 5011 rollover. Servers
# being set up for the first time can use the contents of this
# file as initializing keys; thereafter, the keys in the
# managed key database will be trusted and maintained
# automatically.
. initial-key 257 3 8
"AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
$
Notice that our local DNS server has the new KSK key and we also see the
flag "ad" (Authenticated Data - DNSSEC validated):
$ dig @127.0.0.1 +norecurse +multiline . DNSKEY
...
;; flags: qr ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
...
. 148312 IN DNSKEY 257 3 8 (
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
) ; KSK; alg = RSASHA256; key id = 20326
...
$
Similarly with delv(1), new key shows as fully validated:
$ delv +multiline DNSKEY .
; fully validated
...
. 147480 IN DNSKEY 257 3 8 (
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
) ; KSK; alg = RSASHA256; key id = 20326
...
$
Additional references and resources, etc.:
https://www.icann.org/resources/pages/ksk-rollover#timeline
ICANN: Prepare Your Systems for the Root KSK Rollover:
https://www.youtube.com/watch?v=d7H1AkC9PIw
(as shown in the URL above, recommended to not use:
http://data.iana.org/root-anchors/
but instead use:
https://data.iana.org/root-anchors/
)
TeamNANOG: 2017 DNSSEC KSK Rollover:
https://www.youtube.com/watch?v=eVEGSr3p77M
Got updates?, e.g.:
https://lists.debian.org/debian-stable-announce/2017/09/msg00000.html
https://lists.debian.org/debian-stable-announce/2017/09/msg00001.html
https://lists.debian.org/debian-stable-announce/2017/09/msg00002.html
https://lists.debian.org/debian-stable-announce/2017/09/msg00003.html
https://www.icann.org/resources/pages/ksk-rollover
https://data.iana.org/root-anchors/
There's an excellent DNSSEC troubleshooting tool here:
http://dnsviz.net/
One can see with that, on:
http://dnsviz.net/d/root/dnssec/
the root KSK rollover progress - there are two KSK keys - they are the
ones showing the Flags: 257 (ZONE, SEP) (move your pointer over the
various displayed items). At the present time, both keys are present,
and the old key (id=19036) has signed the new key (id=20326) but the new
key hasn't yet signed other keys - that is scheduled to change 2017-10-11.
One can also examine other zones, e.g. SF-LUG.org - I recently started
roll of ZSK - quite automagic to clients, but one can see the details
here:
http://dnsviz.net/d/sf-lug.org/dnssec/
Note that for sf-lug.org presently, there are two published (in DNS)
ZSK keys (Flags: 256(ZONE)), both are signed by the
KSK key (Flags: 257 (ZONE, SEP)). Which ZSK signs the zone's data will
later be switched (rolled), and then yet later, the older ZSK will get
removed from DNS.
This guide: https://ftp.isc.org/isc/dnssec-guide/dnssec-guide.pdf
includes various algorithms for rolling ZSK and KSK keys - though it
doesn't specifically address the (very) special case of rolling root KSK
key.
Typical recommendation on rolling DNSSEC keys,
roll ZSK keys yearly, and KSK keys every five years.
Different environments may have specific (e.g. regulatory) requirements,
and likewise may have particular requirements on algorithms and key
sizes. There is, however, nothing that inherently/technically requires
that keys be rolled ... but if keys are rolled, one should be able to
suitably process that (and for the most part that's quite automagic -
especially also with implementation of RFC-5011).
If one wants overview and/or details of how the root keys themselves are
handled on the root servers and such, take a look at these:
TeamNANOG: Lightning Talks: Root DNSSEC KSK Rollover:
https://youtu.be/N64erX0QoCw
http://www.root-dnssec.org/wp-content/uploads/2010/05/draft-icann-dnssec-ceremonies-01.txt
Blues Brothers - "Rawhide" ... "rollin', rollin', rollin'" ... :-)
https://youtu.be/RdR6MN2jKYs?t=49
More information about the sf-lug
mailing list