[Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7

Simon Kelley simon at thekelleys.org.uk
Thu May 7 13:54:50 BST 2015


On 07/05/15 10:41, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon at thekelleys.org.uk> writes:
> 
>> It's difficult to see how that would work in practise for DNS. Take
>> the Google-public-DNS example. It's clearly not sane for Google's
>> servers to do PMTU on the address of every client, just to send one
>> UDP packet, and caching PMTU for clients is going to get hard, fast.
>> If the reply-size is bigger than the PMTU what happens anyway?
>> Presumably a truncated response, to force fallback to TCP.
> 
> Well, IPv6 also mandates a minimum PMTU of 1280 bytes. So a source host
> that doesn't do PMTU discovery should either limit itself to 1280 bytes
> packets or fragment at the source. Routers are not going to do it. See
> https://tools.ietf.org/html/rfc2460#section-5 :)

But if they fragment, what size should they fragment to? I guess inthe
absence of any information to the contrary, 1280 bytes. I wonder if the
Google public DNS is failing to do that, or if it is, and the path to me
is dropping fragments?

Simon.

> 
>> I guess it could work the other way around, and the client finds the
>> PMTU to the server, and puts that in the EDNS0 max packet field. Are
>> PMTU symetric?
> 
> I guess that would be reasonable. Or just be on the safe side and always
> set the max packet field to 1280 bytes when querying over IPv6?
> 
>> In any case, good luck updating every stub resolver in the world to do
>> this......
> 
> Well in theory the people updating those same stub resolvers to speak
> IPv6 should pay attention to this, I guess. I'm not holding my breath,
> though... :P
> 
> -Toke
> 




More information about the Dnsmasq-discuss mailing list