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

Geoff Huston gih at apnic.net
Wed Sep 6 00:56:43 UTC 2017

> On 5 Sep 2017, at 9:40 pm, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> On Tue, Sep 05, 2017 at 06:15:13PM +0800,
> Davey Song <ljsong at biigroup.cn> wrote 
> a message of 51 lines which said:
>> I wrote a draft for large response issue(do not submit yet). I have
>> a repo on Github and test script. Comments are welcome.
> I've read it, and it seems OK. Curious to see the dnsop reactions :-)
> Any public zone using it on its authoritative name servers, for
> testing?
>>  Especially regarding the coming KSK rollover, if the root server
>>  implements ATR rather than setting IPv6-edns-size to 1220 octets,
>>  it will helpful for resolver with TCP capacity, because it still
>>  has a fair chance to receive the large response.
> 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”.

In the case of the roots there is no single root server behaviour when passing
back large responses. See http://www.potaroo.net/ispcol/2016-11/rootstars.html
and http://www.potaroo.net/ispcol/2016-12/6thstar.html for the gory details.

Servers on A, B, G and J truncate a large IPv6 response when it exceeds
1280 octets, thereby pushing the client resolver to use TCP,

B and G also do the same for IPv4 large responses.

There is no single “best” way to handle large DNS responses. But for as long
as we have both IPv4 and IPv6, and for as long as we have a diversity of
behaviours in the 13 anycast constellations then a persistent resolver
(i.e. one that is willing to re-query by changing protocols and changing
root server letters) will probably stumble across a root server large
response behaviour that will deliver to them the large answer they are 

More information about the discuss mailing list