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

[Simon Kelley]

On 29/04/14 21:57, Phil Pennock 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".

A valid point, but "every leaf system has to be a recursor" is not a
pleasant outcome of widely implementing DNSSEC. I wonder, do the
browser-based validators suffer from this, or are they recursors under
the hood? This is a judgement for integrators, not for me, but if
there's anything widely deployed enough to act as a lever to get this
fixed, it's dnsmasq.

> 
> So the standards 100% support what you're doing, but they don't match
> common stupidity in deployed (high end, expensive) equipment.
> 
> 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.

That's nice, but it needs recursors to play ball too, so it's even
further into the indefinite future than what we have now.
> 
> Sorry to be the bearer of bad news,

Better to know.


Cheers,

Simon.

> -Phil
>