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

[Dave Taht]

Yes, I was using comcast native ipv6.

On Wed, May 6, 2015 at 1:49 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> 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
>>
>>
>>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67