[Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7
Simon Kelley
simon at thekelleys.org.uk
Wed May 6 21:49:44 BST 2015
This stuff does worry me. It's a big source of brittleness.
One thing that's worth pointing out is that it's not necessarily the
answer to the original query that's too big, it might be the answer to
one of the DS or DNSKEY queries needed to validate it. If the answer to
one of those comes back with the TrunCated bit set, then dnsmasq
abandons the whole thing and returns a TC answer to the original
question so that the requestor tries again in TCP mode. Now the DS or
DNSKEY query gets done in TCP mode too, and the answer isn't truncated.
Dnsmasq doesn't mix TCP and UDP queries in one validation, and always
does the upstream queries in the same mode as the query it's answering.
That explains why it's falling back to TCP even though the final
(signed) answer is 538 bytes.
Doing a quick binary chop. I see fallback to TCP if edns-packet-max is
less then 1625, which is bigger than a ethernet packet. Looking at the
packet capture, I see that it's actually the answer to
DNSKEY org
which is 1625 bytes and fragmented (and reassembled) across my wireless
LAN. Actually, it's probably fragmented somewhere on the other end of
the 3G connection or before. It gets reassembled at this end.
There are four DNSKEYS and the corresponding RRSIGS in that answer. I
wonder if that's intended?
All the above is on IPv4. Dave are you using IPv6? I'll try that next.
Cheers,
Simon.
On 06/05/15 20:42, Dave Taht wrote:
> I retried it with edns0 set to 1500 bytes, and it worked (falling back
> to tcp). 1800 bytes did not.
>
> an osx box was the client.
>
> I did capture the transaction(s) this time, the failing queries and a
> working one are at: http://snapon.lab.bufferbloat.net/~d/dnsmasq/
>
> One of my concerns has always been what fq_codel's algorithm does to
> fragmented packets in general... but I have not looked at this
> captures...
>
> The testing I was doing earlier (where ietf.org worked) was with a
> linux box as the client a few days ago. I will resume testing that
> later today, and also continue slamming dnsmasq with queries over ipv6
> from the alexa top 1m....
>
>
>
> On Wed, May 6, 2015 at 12:30 PM, Kevin Darbyshire-Bryant
> <kevin at darbyshire-bryant.me.uk> wrote:
>> Continues to work here on my iPhone hiding behind openwrt cc trunk dnsmasq2.73rc7
>>
>> Were I not on the iPhone I could do some dig'age :-)
>>
>> --
>> Cheers,
>>
>> Kevin at Darbyshire-Bryant.me.uk
>> Sent from my phone, apologies for brevity, spelling & top posting
>>
>>> On 6 May 2015, at 20:21, Dave Taht <dave.taht at gmail.com> wrote:
>>>
>>> nslookup www.ietf.org fails again... it did not fail a few days ago.
>>>
>>> chrome returns nxdomain
>>>
>>>
>>> --
>>> Dave Täht
>>> Open Networking needs **Open Source Hardware**
>>>
>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>>>
>>> _______________________________________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
>
>
More information about the Dnsmasq-discuss
mailing list