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

[Dave Taht <dave.taht@gmail.com>]

On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
<cerowrt-devel+phil@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?

> -Phil



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article