March 2019 - ksk-rollover - lists.icann.org

Quantum Apocalypse
by Michael StJohns March 28, 2019

March 28, 2019

Retransmitting the points I made at the microphone at the IETF. 1) We don't have a quantum safe signature algorithm that we've selected for DNSSEC and AFAICT, while there are a lot of candidates, even the crypto folks aren't to the point of saying "use this" for any of the candidate algorithms. 2) Once (1) is done, there's at least a few years to agree and produce an RFC. 3) Once (2) is done, there's at least a 5 year uptake period to get the new algorithm support into the resolvers. (And there's the self-same problem that it's impossible for the root publisher to know whether or not a resolver actually supports the new algorithm. It may make sense to actually do a PERT style "what has to happen when and before what" diagram to document the moving pieces and to help figure out if there are any tasks we can complete early (e.g. figuring out how to serve *really big signatures* even if we don't know what the signature mechanism might be). Mike

2 1

Fate sharing
by Olaf Kolkman March 28, 2019

March 28, 2019

As I just mentioned at the #IETF104 BOF. I think there is a fate sharing requirement to be made: DNS infrastructure (authoritative, and recursive servers) that have not bought into the DNSSEC project should not be impacted by the roll. It would be good to understand if there where any resolvers that had resolution issues during the roll while they were not validating. I believe the examples that Geoff gave were about infrastructure that broke because validation was going on (and consequently turned off), but if it is the case that big ISPs lost connectivity while they were not doing DNSSEC validation, because of any stage in key rollover, that would be good to know. Frederico Neves just mentioned to me that 82%+ of queries towards .BR have the DO bit set (even though they may not do validation) which means that they are somewhat bought into any effects caused by transport issues. So maybe that the requirement above may not be realistically met. —Olaf

1 0

Re: [ksk-rollover] A lab test of Root Algorithm Rollover
by Medel Ramirez March 25, 2019

March 25, 2019

Davey, This is super Kool ! Best Medel ++++++++ Sent from my V6 Engine! メデルラミレズ On 25 Mar 2019, at 1:42 PM, Davey Song(宋林健) <ljsong(a)biigroup.cn> wrote: Hi folks, We have done a lab test against the root algorithm rollover last month. There is a preliminary result and supprise I would like to share with you if you are interested. I also would like to call for more participants (resolvers) and input for our second lab test. Comments are welcome. The Slides I presented in Yeti DNS workshop: https://yeti-dns.org/resource/Root-algorithm-rollover-lab-test.pdf The summary I quoted from the meeting note of my presentation: “Basically, we rolled the algorithm in four approaches with different configuration and time lines. The finding is interesting that four approaches successfully for BIND (9.11.5-P1) and UNBOUND(1.8.3) resolver. Note that there is an accidental mistake in configuring the ZSK's inactive time which results no active signing key in the middle of the rollover and causes validation failure(we recovered it with a new ZSK but it still had impact on resolver). As a response to this failure, it is observed BIND restarts the Add Hold-Down Time of new key/algorithm for another 30 days when new valid signing key is available but Unbound continue the timer and trusted the KSK/Algorithm after the rfc5011-timer expired. It is planned that more lab test for rollover should be done before roll the algorithm of Yeti. We will call for more resolvers to join this test.” Best regards, Davey _______________________________________________ ksk-rollover mailing list ksk-rollover(a)icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover -- This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately.

1 0

Re: [ksk-rollover] 答复: A lab test of Root Algorithm Rollover
by James Gannon March 25, 2019

March 25, 2019

Thanks Davey! From: "Davey Song(宋林健)" <ljsong(a)biigroup.cn> Date: Monday, 25 March 2019 at 07:07 To: James Gannon <james(a)cyberinvasion.net>, "ksk-rollover(a)icann.org" <ksk-rollover(a)icann.org> Subject: 答复: [ksk-rollover] A lab test of Root Algorithm Rollover Sorry. I did not push it to my remote repo yet. Now it is available. Or you can check the attached file Davey 发件人: James Gannon [mailto:james@cyberinvasion.net] 发送时间: 2019年3月25日 13:52 收件人: Davey Song(宋林健); ksk-rollover(a)icann.org 主题: Re: [ksk-rollover] A lab test of Root Algorithm Rollover I get a 404 from that url? From: ksk-rollover <ksk-rollover-bounces(a)icann.org<mailto:ksk-rollover-bounces@icann.org>> on behalf of "Davey Song(宋林健)" <ljsong(a)biigroup.cn<mailto:ljsong@biigroup.cn>> Date: Monday, 25 March 2019 at 06:42 To: "ksk-rollover(a)icann.org<mailto:ksk-rollover@icann.org>" <ksk-rollover(a)icann.org<mailto:ksk-rollover@icann.org>> Subject: [ksk-rollover] A lab test of Root Algorithm Rollover Hi folks, We have done a lab test against the root algorithm rollover last month. There is a preliminary result and supprise I would like to share with you if you are interested. I also would like to call for more participants (resolvers) and input for our second lab test. Comments are welcome. The Slides I presented in Yeti DNS workshop: https://yeti-dns.org/resource/Root-algorithm-rollover-lab-test.pdf The summary I quoted from the meeting note of my presentation: “Basically, we rolled the algorithm in four approaches with different configuration and time lines. The finding is interesting that four approaches successfully for BIND (9.11.5-P1) and UNBOUND(1.8.3) resolver. Note that there is an accidental mistake in configuring the ZSK's inactive time which results no active signing key in the middle of the rollover and causes validation failure(we recovered it with a new ZSK but it still had impact on resolver). As a response to this failure, it is observed BIND restarts the Add Hold-Down Time of new key/algorithm for another 30 days when new valid signing key is available but Unbound continue the timer and trusted the KSK/Algorithm after the rfc5011-timer expired. It is planned that more lab test for rollover should be done before roll the algorithm of Yeti. We will call for more resolvers to join this test.” Best regards, Davey

1 0

Re: [ksk-rollover] A lab test of Root Algorithm Rollover
by James Gannon March 25, 2019

March 25, 2019

I get a 404 from that url? From: ksk-rollover <ksk-rollover-bounces(a)icann.org> on behalf of "Davey Song(宋林健)" <ljsong(a)biigroup.cn> Date: Monday, 25 March 2019 at 06:42 To: "ksk-rollover(a)icann.org" <ksk-rollover(a)icann.org> Subject: [ksk-rollover] A lab test of Root Algorithm Rollover Hi folks, We have done a lab test against the root algorithm rollover last month. There is a preliminary result and supprise I would like to share with you if you are interested. I also would like to call for more participants (resolvers) and input for our second lab test. Comments are welcome. The Slides I presented in Yeti DNS workshop: https://yeti-dns.org/resource/Root-algorithm-rollover-lab-test.pdf The summary I quoted from the meeting note of my presentation: “Basically, we rolled the algorithm in four approaches with different configuration and time lines. The finding is interesting that four approaches successfully for BIND (9.11.5-P1) and UNBOUND(1.8.3) resolver. Note that there is an accidental mistake in configuring the ZSK's inactive time which results no active signing key in the middle of the rollover and causes validation failure(we recovered it with a new ZSK but it still had impact on resolver). As a response to this failure, it is observed BIND restarts the Add Hold-Down Time of new key/algorithm for another 30 days when new valid signing key is available but Unbound continue the timer and trusted the KSK/Algorithm after the rfc5011-timer expired. It is planned that more lab test for rollover should be done before roll the algorithm of Yeti. We will call for more resolvers to join this test.” Best regards, Davey

2 1

A lab test of Root Algorithm Rollover
by Davey Song(宋林健) March 25, 2019

March 25, 2019

Hi folks, We have done a lab test against the root algorithm rollover last month. There is a preliminary result and supprise I would like to share with you if you are interested. I also would like to call for more participants (resolvers) and input for our second lab test. Comments are welcome. The Slides I presented in Yeti DNS workshop: https://yeti-dns.org/resource/Root-algorithm-rollover-lab-test.pdf The summary I quoted from the meeting note of my presentation: “Basically, we rolled the algorithm in four approaches with different configuration and time lines. The finding is interesting that four approaches successfully for BIND (9.11.5-P1) and UNBOUND(1.8.3) resolver. Note that there is an accidental mistake in configuring the ZSK's inactive time which results no active signing key in the middle of the rollover and causes validation failure(we recovered it with a new ZSK but it still had impact on resolver). As a response to this failure, it is observed BIND restarts the Add Hold-Down Time of new key/algorithm for another 30 days when new valid signing key is available but Unbound continue the timer and trusted the KSK/Algorithm after the rfc5011-timer expired. It is planned that more lab test for rollover should be done before roll the algorithm of Yeti. We will call for more resolvers to join this test.” Best regards, Davey

1 0

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

followup of DNSSEC Workshop at ICANN64
by Yoshiro YONEYA March 22, 2019

March 22, 2019

Hi all, During DNSSEC Workshop at ICANN64, there were discussion regarding future KSK rollover. https://64.schedule.icann.org/meetings/961939 This is followup what I said. I support regular Root Zone KSK Rollover for operational maturity and DNS software matulity. The importance is doing regulary. Frequency may be once per 2-3 years, less than 5 years. -- Yoshiro YONEYA

15 27

DNSKEY queries, was Re: followup of DNSSEC Workshop at ICANN64
by Tony Finch March 18, 2019

March 18, 2019

Warren Kumari <warren(a)kumari.net> wrote: > but, I think that we first need to figure out what the cause of the > increase in DNSKEY lookups is - it concerns me that we predicted no > impact from the revocation, and we got... this. Following this comment I had a quick tcpdump on my resolvers to see if there was anything doing stupid quantities of . IN DNSKEY queries. There is one firewall that is relatively busy (I dunno what is behind it), but what surprised me was the volume of queries from our wireless networks. I had thought that end-user sub validation was negligible, but it seems to be relatively common. We typically have about 30k devices associated on our wireless network, so I would expect very roughly 2*86400/30000 = 6 seconds between queries if everyone is validating. Eyeballing it, I'm seeing maybe 10s between queries. Maaybe Windows-related? I don't have any easy way to investigate further. Of course my resolvers will be absorbing this traffic so the roots won't see it. But I thought it might be of interest. $ tcpdump -s0 -vvv -p -i eno1 udp and dst port 53 and udp[20] == 0 and udp[21] == 0 and udp[22] == 48 Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ fight poverty, oppression, hunger, ignorance, disease, and aggression

1 0

Review of the 2018 DNSSEC KSK Rollover
by Paul Hoffman March 15, 2019

March 15, 2019

Greetings again. ICANN has published an extensive review of the KSK rollover. Please see: https://www.icann.org/review-2018-dnssec-ksk-rollover.pdf We hope this is useful in the planning of future rollovers. --Paul Hoffman

2 1