[Yeti DNS Discuss] 答复: ATR: Additional Truncated Response for Large DNS Response

Davey Song(宋林健) ljsong at biigroup.cn
Wed Sep 6 03:06:21 UTC 2017


> I've read it, and it seems OK. Curious to see the dnsop reactions :-)

After feedback from this mailing list, I will submit it to dnsop.

> Any public zone using it on its authoritative name servers, for testing?

Yeti is a perfect place to do this testing, but we lack of resolver and traffic. Last week I proposed this idea face-to-face to ICANN CTO David Conrad when he visit Beijing. I'm think of encouraging his team to do some test as well. 
 
> Note that, even in the best case, ATR won't be significantly deployed before the
> root key rollover. So, it may be better to replace "it will" by "it would have
> help".
OK, I will edit it.

> 
> > DNS TCP function is stripped even for modern DNS implementations
> 
> There are many reasons why 17 % of resolvers cannot use TCP. It's not always
> the resolver's fault, it can be a stupid middlebox in the path.

OK. I will make some changes on the problem description.

I once suspected myself when I finished this draft, because the benefit of ATR may be too trivial to implement. Resolver can retire 12 times if one path to particular root server failed. The performance comparison between retries with other NS server and ATR is hard to measure. 

But I still have a little confidence on ATR for some cases:

1) For those root servers implemented or plan to implement "always-truncation" for large packets, they can benefit from not doing unnecessary TCP fall back.   

2) For those area or countries where only one or two root instance are deployed (China for example), stick to the local root server (with around 10ms latency for UDP and roughly around 30ms for TCP) is better than select another NS server far away (with around 200ms latency)

3) One last case (imagined, may be not true), from marketing point of view, if we can make a analogy that root server operators are competing for customer (traffic from resolvers), they do not want to lose their customer and business : ) 

Davey






More information about the discuss mailing list