[Yeti DNS Discuss] Dealing with IPv6 Fragmentation in the DNS

Geoff Huston gih at apnic.net
Sun Sep 3 23:36:41 UTC 2017

> On 4 Sep 2017, at 8:19 am, Paul Vixie <paul at redbarn.org> wrote:
> Geoff Huston wrote:
>> ...
>> The problem is that if you use a low MTU then you need to fragment
>> your response if the response is larger than your MTU. The problem is
>> that fragmenting the response means that there is a far change (more
>> than 1 in 3) that you may be using a recursive resolver that cannot
>> receive a fragmented DNS response over IPv6. Google’s public DNS
>> service, for example.  ...
> i do not believe that google's network, or servers, or dns app, filters out the extension headers or icmp messages needed for end-to-end ipv6 fragmentation and reassembly to work correctly. if they did then this would be an easy fix, since google is competent and well-intentioned.

My probing from various vantage points tends towards a different conclusion, namely that Google’s public DNS service does not receive fragmented IPv6 over UDP DNS responses from authoritative name servers. I also suspect that Google have the clue to fix this. 

> rather, i believe that middleboxes and middlemen (and middlewomen?) are keeping google from hearing this signalling. if i'm right, then those are the boxes and people that need a clue-by-four upside their heads. we watched EDNS deployment stall due to this same rampant cluelessness.

rampant cluelessness is another factor, yes.

I can see a number of responses to this problem - one is to increase the pain level for networks that have deployed equipment that exhibts this behaviour. Another is to modify the protocol behaviour to try and avoid the problem.

The issue with the first approach is that for as long as dual stack DNS exists IPv4 will patch up this problem seamlessly: IPv6 query doesn't respond? Try again using IPv4. Bingo! So the pain will only be noticeable when we finally get around to dropping IPv4 off the Internet, and I worry that at that strange the behaviour of dropping EH packets is so entrenched it will be hard to change.

I have a lot of sympathy with the second approach. Sone resolver code already performs this to some extent by re-querying with lower EDNS(0) UDP buffer sizes when the auth server appears to be unresponsive. 



More information about the discuss mailing list