- ksk-rollover - lists.icann.org

Press release about the ICANN Board passing resolution on the KSK rollover
by Paul Hoffman Sept. 19, 2018

Sept. 19, 2018

https://www.icann.org/resources/press-material/release-2018-09-18-en

1 0

KSK rollover IETF RFCs?
by Rene 'Renne' Bartsch, B.Sc. Informatics Sept. 18, 2018

Sept. 18, 2018

Hi, which IETF RFCs define the KSK rollover for resolvers? Regards, Renne

2 1

Current status of KSK-RollOver?
by Rene 'Renne' Bartsch, B.Sc. Informatics Sept. 10, 2018

Sept. 10, 2018

Hi, how are the chances to make the 10/11/2018 for the Root Zone KSK Rollover? Regards, Renne

11 21

ICANN Publishes Comprehensive Guide on What to Expect During the Root KSK Rollover
by Paul Hoffman Aug. 23, 2018

Aug. 23, 2018

Greetings again. Please see the announcement of a new guide at https://www.icann.org/news/announcement-2018-08-22-en and the guide itself at https://www.icann.org/en/system/files/files/ksk-rollover-expect-22aug18-en.… We welcome comments on the guide and its contents. --Paul Hoffman

1 0

RFC 8145 interaction with Aggressive DNSSEC cache
by Petr Špaček July 26, 2018

July 26, 2018

Hello, here is one additional caveat about RFC 8145 signaling which I did not see mentioned anywhere: As long as RR "_TA-4A5C-4F66. NULL" does not exist in the root zone, any resolver which implements RFC 8145 (signaling) together with either of - Aggressive Use of DNSSEC-Validated Cache (RFC 8198) - Decreasing Access Time to Root Servers by Running One on Loopback (RFC 7706) is likely not to send signaling queries to the root. If the resolver implemented only RFC 8198 it might send query from time to time but it very much depends on state of its cache and cannot be relied on. RFC 7706 stops signaling queries altogether. The problem with aggressive cache could be solved by adding the _TA records to the root but I'm not sure if it is worth the effort. Are there any results using the KSK root sentinel method? -- Petr Špaček @ CZ.NIC

5 8

Now publishing updated RFC8145 graphs and IP addresses of resolvers reporting
by Matt Larson June 15, 2018

June 15, 2018

We wanted to let everyone know that we've updated the graphs of RFC 8145 data we're receiving. In addition, as of today, we've also started publishing the list of individual addresses that are sending RFC 8145 data indicating they are configured with only KSK-2010 as a trust anchor. See this page for more information about both the graphs and the list of addresses: http://root-trust-anchor-reports.research.icann.org While the graphs show an "up and to right" trend in the number of sources reporting only KSK-2010, Wes Hardaker has done some excellent research and found what he believes is the source for many of these queries; more details are on that page, as well. Matt

7 8

(no subject)
by Ronald Chapman May 1, 2018

May 1, 2018

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

1 0

Staff report of the public comments on the new KSK rollover plan
by Paul Hoffman April 24, 2018

April 24, 2018

Greetings. As promised, we have prepared a staff report of the comments we received on the KSK rollover plan. You can see it here: https://www.icann.org/en/system/files/files/report-comments-ksk-rollover-re… Next up: a revised plan with additions based on the many suggestions we received. Thanks again for everyone who contributed public comments! --Paul Hoffman

3 2

Re: [ksk-rollover] 答复: Architectural reconsideration on ICANN's Root Zone KSK rollover
by Robert Story Feb. 26, 2018

Feb. 26, 2018

On Wed 2018-01-31 10:55:53+0800 Davey wrote: > So I'm inspired that it is not necessary for additional set of root > server and coordination between server and resolver > for this purpose. All the work can be done in server side. This is true. > It can be implemented on server side with "two logic views"(similar > but different from BIND multiple view mechanism. > When authoritative server recognize the resolvers who support RFC5011 > (via rfc8145 or combined with kskroll-sentinel), > it can roll the key only for them. Roll KSK not once for all but > per-resolver. In that case there is no need any modification on > resolver. Root server operator should do this work only. So there is > no interoperability problem. No specification of DNS is > needed which shorten the time and concerns. There is still risk in this. Many end users are behind NATs. This means that some queries from an IP can signal that it is using the new key, while others could signal it is not. Instead of making this some sort of automatic process, it could be entirely opt-in if root-servers configured views based on destination address and simply listened on an additional anycast address. But this still leaves the problem of how to advertise the new address, and wouldn't deal with the problem of resolvers which switched to the new address even though they weren't configured to trust the new keys. If we could convince the resolver implementations to ship with multiple hints files, and to selected on at startup based on configured trust anchors, we could see the traffic shift are resolvers were updated. -- Robert Story <http://www.isi.edu/~rstory> USC Information Sciences Institute <http://www.isi.edu/>

4 4

Re: [ksk-rollover] Concerns about KSK generation software quality.
by S Moonesamy Feb. 23, 2018

Feb. 23, 2018

Hi Warren, At 11:59 AM 16-02-2018, Warren Kumari wrote: >In the "Suggested update" thread, Andres pointed me [snip] >While typos in error messages and comments are (clearly) not going to >cause breakage, it does make me concerned that this code, which >generates the single most critical DNSSEC keys, has not received >sufficient careful review. These sorts of obvious typos are not >themselves a problem, but rather indicative of a larger issue. While >the obvious retort is "It is publicly posted in GitHub, and we asked >the community to have a look. Send pull requests!", it appears that >this hasn't resulted in enough review. I used to program C, but it has >been long enough that now I'm only qualified to say "Well, that >doesn't seem right!" - how do we get (more) review from people who are >better qualified? I agree that the software could be improved with a code review. As far as I am aware, nobody else uses that software and that does not help to get enough review. Regards, S. Moonesamy

1 0