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

[Simon Kelley]

Forwarding something from a parallel conversation to the list.

Simon.


-------- Forwarded Message --------
Subject: Re: testing edns0 on bind
Date: Thu, 7 May 2015 09:58:56 -0700
From: Evan Hunt <each at isc.org>
To: Simon Kelley <simon at thekelleys.org.uk>
CC: Dave Taht <dave.taht at gmail.com>, Toke Høiland-Jørgensen <toke at toke.dk>

> This is my hypothesis, which fits what I'm seeing, but is not the
> only one possible. I've not exhaustively checked if it's what Dave
> is seeing.
> 
> Dnsmasq forwards the www.ietf.org query to the Google server and
> gets back the result. It then starts to validate, and ends up
> sending the query for DNSKEY .org to the Google public DNS. In that
> query, it sets the EDNS0 UDP packet size to 4096. Google gets the
> answer which is 1600-ish bytes long, less than 4096, so it sends
> the answer back by UDP. This has to be fragmented (by Google -
> routers don't fragment in IPv6 world). Either the fragmentation is
> not happening and the oversize packet gets dropped, or the
> fragmentation fails and the packet gets dropped, or the
> fragmentation succeeds but the fragments are dropped somewhere
> between there and here. In any event, no answer is forthcoming, and
> eventually the whole query times out and fails.

So all .org domains are failing validation, not just ietf.org?  I
thought it was just
ietf.org, which would suggest a different sort of problem.  But if
it's all of them
then you're probably correct.

> Limiting dnsmasq to a packet size of 1280 causes it to set the
> EDNS0 UDP paacket size to 1280 in the query. Google notice s that
> 1280 is less than 1600-ish and returns a truncated answer. The
> whole thing gets retried over TCP and succeeds.
> 
> Using the Google public IPv4 servers, I can see the large UDP
> reply arriving as two fragments, which are succesfully reassembled
> and it all works.
> 
> The problem with the EDNSO packet size stuff, is that it seems to
> work to make the various bits of the DNS ecosystem generate and
> handle large packets, but blythely ignores that fact that the UDP
> transport doesn't guarantee to handle them. As Toke pointed out, an
> IPv6 node MUST reassemble only 1500 byte packets.

Right, I'd forgotten that.  There are actually *two* intermediate
steps between 512
and 4096 in BIND -- 1232 and 1432, which are chosen to allow
encapsulated UDP
messages to be sent at the minimum MTU's for v4 and v6 networks,
respectively.

Rethinking what I said earlier, I'd suggest for dnsmasq that you still
always try a
query first at 4096, and if no answer arrives within some number of
milliseconds, try again
with TCP.  After a certain number of failures at 4096, you could lower
the default for that
server.  Unfortunately you can't rely on starting at 1280 to solve
your problems; it may still
end up failing if you're behind an ancient firewall that thinks DNS
packets are always 512
bytes or less and drops anything bigger (far too man of these idiot
milddboxes are still
out there causing trouble).

E