January 2019 - ksk-rollover

Increased DNSKEY queries to the root servers since the KSK-2010 revocation
by Paul Hoffman March 22, 2019

March 22, 2019

Greetings again. Soon after the new DNSKEY RRset was published at 1400 UTC on 11 January 2019 with KSK-2010 revoked, there was a noticeable increase in ./IN/DNSKEY queries sent to root servers. While we have heard of no DNS service interruption for users, the average DNSKEY query load over all servers has more than doubled to between 2% and 2.5%. The increase was quite varied between the different root servers; some experienced almost no increase at all, while others experience an increase of up to 5%. Although some resolvers are newly making rapid queries to the root servers for the root’s DNSKEY RRset, we see no indication that those resolvers are failing to answer DNS queries from their customers. We will continue to monitor the situation. The ICANN organization is evaluating the traffic at the L-root to try to characterize the resolvers that are rapidly asking for the root’s DNSKEY RRset. From this, we can determine if we are able to help the operators of those resolvers to remediate this anomalous behavior. We will also share data with other root server operators who are conducting similar investigations. The results will be reported when our analysis is complete. --Paul Hoffman

10 10

Any potential correlation between the roll over and the recent notice by the US Department of Homeland Security on DNS Cyber Attacks?
by Lee Neubecker Jan. 25, 2019

Jan. 25, 2019

I wanted to make sure you were all aware of several notices issued which came just before and after the root key change over for DNS. Bad actors with access to the older private key root (if compromised) may have been motivated to strike before the key change over. https://www.cyberscoop.com/dhs-dns-directive-government-shutdown/ This alert went out the day before change over on January 10th, 2019. https://www.us-cert.gov/ncas/current-activity/2019/01/10/DNS-Infrastructure… This alert on January 22nd, 2019 https://cyber.dhs.gov/ed/19-01/ This alert was issued yesterday https://www.us-cert.gov/ncas/alerts/AA19-024A The timing of this change over taking place roughly 2+ weeks after the U.S. Government Shutdown is a little unfortunate, since the switch over date may have encouraged attacks before the old key was revoked. I do think the re-key is a good idea, and agree with Tony Finch on the concept of "[I favour annual rollovers, with keys generated and promulgated out of band a few years in advance, and at most two KSKs in the root zone at any time.]" I welcome any comments. Lee Neubecker, CISSP President & CEO GreatLakesForensics.com 65 W. Jackson Blvd., Suite 101 Chicago, IL 60604 Toll Free/Fax: 888-503-0665 https://greatlakesforensics.com Computer Forensics · Cyber Security Readiness & Response · Online Identity Investigations Check out my security blog at https://leeneubecker.com

2 1

Re: [ksk-rollover] Increased DNSKEY queries to the root servers since the KSK-2010 revocation
by Wessels, Duane Jan. 16, 2019

Jan. 16, 2019

On 1/15/19, 3:53 PM, "Geoff Huston" <gih(a)apnic.net> wrote: Does this have anything to do with the observation that A and J truncate large IPv6 UDP responses No, I don't think so. In the data that I've look at so far, it's been IPv4 sources exhibiting this rollover-and-die[1] behavior. We do observe an increase in truncation during ZSK rollovers. But at revocation, the overall truncation rate dropped a little, almost certainly due to the increase in volume from misbehaving sources. Admittedly that could be masking truncation from other sources so I'll take a closer look. DW [1] I wish they would.

1 0

RFC 5011 will not be implemented in Dnsmasq
by Rene 'Renne' Bartsch, B.Sc. Informatics Jan. 14, 2019

Jan. 14, 2019

Hi, according to Simon Kelly RFC 5011 is not sufficient for automatic DNSSEC key updates and will not be implemented in Dnsmasq (https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg124…) As the majority of SoHo routers uses Dnsmasq as DNS resolver I suggest to address this problem by discussing a suitable solution with Simon Kelly and the IETF workgroups. Regards, Renne

6 9

Root zone KSK-2010 is now revoked
by Matt Larson Jan. 11, 2019

Jan. 11, 2019

Dear colleagues, A few moments ago, at 1400 UTC today, 11 January 2019, ICANN's root zone management partner, Verisign, published root zone serial number 2019011100 with the RFC 5011 REVOKE bit set. As a result, KSK-2010's key tag has changed from 19036 to 19164. In addition, the root DNSKEY RRset is now signed with two KSKs: the current KSK (KSK-2017) as well as the former KSK (KSK-2010). The second signature is required by RFC 5011 to prove possession of KSK-2010's private key to assert the revocation. This second signature makes the response to a query for the root zone's DNSKEY RRset increase in size from 1414 bytes to 1425 bytes. We don't expect any operational issues from this change. The DNSKEY RRset size increase is small, and other zones currently publish considerably larger apex DNSKEY RRsets without apparent issue. In addition, because KSK-2010 has not been used for signing since the root KSK rollover to KSK-2017 on 11 October 2018, no DNSSEC validators that are currently validating correctly can be depending on it. Nevertheless, please let us know if you suspect any issues or have any questions. For the root zone management partners, Matt -- Matt Larson, VP of Research ICANN Office of the CTO matt.larson(a)icann.org

1 0

Revoking KSK-2010 imminent
by Chris Thompson Jan. 7, 2019

Jan. 7, 2019

With the revoking of KSK-2010 in the root DNSKEY RRset due in 5 days time, is no one at all nervous about possible consequences? A couple of more specific question: 1. This has been asked before, but is anyone analysing the RFC 8145 data to see how many servers are reporting that they only trust KSK-2017, and are they in a position to track how this changes during the revoking process? The graphs at http://root-trust-anchor-reports.research.icann.org/ are described in terms of servers trusting only KSK-2010 vs. all others. 2. In the unlikely event that publishing a revoked KSK-2010 causes significant problems (e.g. the new high water mark for the size of a signed DNSKEY response has been mentioned), do ICANN have a back-off strategy (e.g. to delay the revoking)? -- Chris Thompson Email: cet1(a)cam.ac.uk

7 10