[Yeti DNS Discuss] Two-responses to Large-response query Rw: Observation on Large response issue during Yeti KSK rollover

[Davey Song(宋林健)]

Regarding the IPv6 fragmentation issue there are two kinds of cost: one is
the latency after timeout and retries, finally succeed using TCP, another is
failure to get any answers(assumption that 17% resolver not support TCP).
We can only say good luck for the later. But for the former, maybe we can do
something good. For example, it was once proposed that the auth server can
always truncate the response if the packets size succeed certain limit
regardless of EDNS0 buffer size. 

 

I’m wondering is it possible that auth server(root) can reply two
responses: both ordinary large packets and packets with TC bit set( maybe
with 10 ms latency). It expected  the resolver can receive the large
response or fallback to TCP as soon as possible if the fragments dropped in
the middle. 

 

Davey

 

发件人: discuss [mailto:discuss-bounces at lists.yeti-dns.org] 代表 Davey
Song(宋林健)
发送时间: 2017年8月2日 9:36
收件人: discuss at lists.yeti-dns.org
主题: [Yeti DNS Discuss] Observation on Large response issue during Yeti KSK
rollover

 

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-yeti-ksk
-rollover.html

 

The conclusion is quoted as follows:

 

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 1%
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, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yeti-dns.org/pipermail/discuss/attachments/20170818/47c0eb63/attachment.html>