[ksk-rollover] Observation on Large response issue during Yeti KSK rollover

[Edward Lewis]

Apologies for not answering sooner, travelling last week and then out of the office on Friday.  I saw the post earlier, just couldn't respond.

 

We've been tracking this issue.  The measurements we relied upon were done some time ago, as Jaap mentions via Geoff Huston's work.

 

What we have been doing in addition includes - tracking the existing deployment of large-ish key sets across Top Level Domains.  (I.e., there's already operational experience with the situation.)  

 

One of the tests done is described at the URL coming up.  (It's not as extensive as a fleet of RIPE anchors though.)

 

https://www.youtube.com/watch?v=sc2J5w4Zi2g&list=PLQziMT9GXafWAdedvzQYmqvW3N7SEo5_e&index=5

 

We've also been recommending, via talks at operator venues, to run TCP and have also presented DNS-OARC's and Verisign's response size tests.

 

See slide 27 of https://ripe74.ripe.net/presentations/25-RIPE74-lewis-submission.pdf.  BTW, slide 25, leading up to that, was inspired by Yoneya(-san) Yoshiro of JPRS.

 

On 8/2/17, 02:31, "ksk-rollover-bounces at icann.org on behalf of Davey Song(宋林健)" <ksk-rollover-bounces at icann.org on behalf of ljsong at biigroup.cn> wrote:

 

Hi ICANN KSK rollover team, 

 

For your information, I have an observation on large response impacts during Yeti KSK rollover. Please check the article.

 

http://yeti-dns.org/yeti/blog/2017/08/02/large-packet-impact-during-yeti-ksk-rollover.html 

 

Best regards,

Davey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20170807/8d42d14c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4586 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20170807/8d42d14c/smime.p7s>