[Yeti DNS Discuss] 答复: 答复: Observation on Large response issue during Yeti KSK rollover

[Davey Song(宋林健)]

I made a edit again including ICANN KSK rollover impact analysis. The packet size will reaches1414 bytes on 2017-Sept-19.

"In ICANN’s KSK rollover plan, the packet size will exceed 1280 Octets limit up to 1414 octets on 2017-Sept-19 and 1424 octets on 2018-Jan-11. It means around 2% IPv6 resolvers(or IPv6 DNSKEY queries with DO bit set) will experience timeout. One study shows that 17% of resolvers cannot ask a query in TCP. So probably in extreme case there are 0.34% of all resolvers around the world will fail to validate the answers. 0.34% of millions, It is not a trivial number."

Davey

> -----邮件原件-----
> 发件人: discuss [mailto:discuss-bounces at lists.yeti-dns.org] 代表 Davey
> Song(宋林健)
> 发送时间: 2017年8月3日 9:47
> 收件人: 'Hugo Salgado-Hernández'
> 抄送: discuss at lists.yeti-dns.org
> 主题: [Yeti DNS Discuss] 答复: Observation on Large response issue during
> Yeti KSK rollover
> 
> I edited the conclusion part :
> 
> The monitoring result shows that statistically large packets will trigger higher
> failure rate (around 7%) due to IPv6 fragmentation issues, which accordingly
> increase probability of retries and TCP fallback. It should be noted that during
> the KSK rollover and other experience in Yeti testbed, no error report was
> spotted directly due to packet size problem (less than 10% likely to cause
> timeout). So it is should be further observed and evaluate the impact of large
> packets issue.
> 
> To avoid less than 10% anomaly inside DNS transaction, one direct solution is to
> hold the a certain size as a boundary for response, like 512-octets was hold for
> a long time in DNS specification. In IPv6 era, a new boundary 1220 octets was
> proposed in APNIC blog posts. I would like to ask is it worthwhile to take any
> heavier measures to this issue? Does it sound like a plan to use stateful
> connection in the first place to transmit DNS like TCP or HTTP for queries
> causing large response, or fragment the packets in the DNS layer?
> 
> Davey
> 
> > -----邮件原件-----
> > 发件人: Hugo Salgado-Hernández [mailto:hsalgado at nic.cl]
> > 发送时间: 2017年8月3日 0:55
> > 收件人: Davey Song(宋林健)
> > 抄送: discuss at lists.yeti-dns.org
> > 主题: Re: [Yeti DNS Discuss] Observation on Large response issue during
> > Yeti KSK rollover
> >
> > On 09:35 02/08, Davey Song(宋林健) wrote:
> > > Hi folks,
> > >
> > >
> > >
> > > I put a article to introduce some observations during Last Yeti KSK
> > > rollover which is finished in this May.
> > >
> > > http://yeti-dns.org/yeti/blog/2017/08/02/large-packet-impact-during-
> > > ye
> > > ti-ksk
> > > -rollover.html
> > >
> > >
> > >
> > > The conclusion is quoted as follows:
> > >
> > >
> > >
> > > The monitoring result shows that statistically large packets will
> > > trigger higher failure rate (around 0.7%) due to IPv6 fragmentation
> > > issues, which
> >
> > Hi Davey.
> > Sorry, maybe I'm misunderstanding, but I see 2,920 failures out of
> > 42,459 total queries in the table, so that accounts on almost 7% !
> >
> > Best,
> >
> > Hugo
> >
> > > accordingly increase probability of retries and TCP fallback. It
> > > should be noted that during the KSK rollover and other experience in
> > > Yeti testbed, no error report was spotted directly due to packet
> > > size problem (less than 1% likely to cause timeout). So it is should
> > > be further observed and evaluate the impact of large packets issue.
> > > To avoid less than 1% anomaly, we can consider is it worthwhile to
> > > take any measures to this issue? Does it sound like a plan to use
> > > stateful connection in the first place to transmit DNS like TCP or
> > > HTTP for queries causing large response, or
> > > <https://tools.ietf.org/html/draft-muks-dns-message-fragments-00>
> > > fragmenting the packets in the DNS layer?
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Davey
> > >
> >
> > > _______________________________________________
> > > discuss mailing list
> > > discuss at lists.yeti-dns.org
> > > http://lists.yeti-dns.org/mailman/listinfo/discuss
> 
> 
> 
> 
> _______________________________________________
> discuss mailing list
> discuss at lists.yeti-dns.org
> http://lists.yeti-dns.org/mailman/listinfo/discuss