[sf-lug] postponed: Re: DNSSEC - 2017-10-11 ROOT KSK KEY ROLLOVER!!!
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Sun Oct 15 21:52:18 PDT 2017
Well, that got postponed ...
"tentatively hoping to reschedule the Key Roll for the first quarter of 2018"
https://www.icann.org/news/announcement-2017-09-27-en
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> To: SF-LUG <sf-lug at linuxmafia.com>
> Subject: DNSSEC - 2017-10-11 ROOT KSK KEY ROLLOVER!!!
> Date: Sun, 01 Oct 2017 12:26:32 -0700
> 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