[Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

On 30/04/14 18:26, Dave Taht wrote:
> On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
> <cerowrt-devel+phil at spodhuis.org> wrote:
>> On 2014-04-29 at 14:22 +0100, Simon Kelley wrote:
>>> secure no DS means that the original unsigned answer should be accepted,
>>> except that it shouldn't. There's no way to distinguish between secure
>>> lack of DS because we've reached an unsigned branch of the tree, and
>>> secure lack of DS because we're not at a zone cut, except if we know
>>> where the zone cuts are, and we don't.
>>
>> Fair point.
>>
>>> That's why dnsmasq works up from the bottom. The first secure no-DS
>>> answer we find marks the boundary between signed and unsigned tree.
>>>
>>> Dnsmasq is acting as a validating stub resolver here. That's a supported
>>> role for DNSSEC, so this must be possible. If it's not then we have a
>>> standards problem.
>>
>> You have a standards vs reality problem: lots of loadbalancer appliances
>> suck at DNS and are only just now managing to return errors, instead of
>> dropping the query (hanging), when queried for AAAA records instead of A
>> records.
>>
>> ( This has led to no end of pain in the IPv6 world; Happy Eyeballs,
>>   expectations around improved _client_ behaviour, handle other parts of
>>   the puzzle and tends to require the concurrency that a client also
>>   needs to handle DNS problems, but it's still distinct. )
>>
>> You're not going to get such loadbalancers responding sanely to a DS
>> query any time soon, and with the other DNS client software all being
>> recursors which work fine because they know where zone cuts are, you're
>> going to be fighting a long hard battle with vendors and sites to get
>> them to fix their brokenness when "it works for everyone else".
>>
>> So the standards 100% support what you're doing, but they don't match
>> common stupidity in deployed (high end, expensive) equipment.
> 
> The only idea I have is to adopt some sort of whitelisting technology,
> and simultaneously nag the folk with busted implementations.
> 
>>
>> To support DNSSEC in the real world without changing from being a
>> forwarder, you're going to need new insight.  My only thoughts are
>> around whether or not this might provide impetus for TKEY-based TSIG for
>> forwarders to establish trust links to recursors elsewhere, in which
>> case once you have a TSIG key (whether TKEY-derived or OOB manual) then
>> you might delegate trust to the remote recursor.
> 
> I see there have been a few commits to dnsmasq that address some stuff.
> 
>>
>> Sorry to be the bearer of bad news,
> 
> I'm delighted to have got this far.
> 
> Is the consensus to not run with negative proofs on at this juncture?

If you want stuff to just work, turn off negative proofs, if you want to
push the envelope, leave them on and complain to domain-admins.

I had some feeling that something like this might be a problem, hence
the discrete controls.


Cheers,

Simon

> 
>> -Phil
> 
> 
>