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

[Phil Pennock <cerowrt-devel+phil@spodhuis.org>]

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.

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.

Sorry to be the bearer of bad news,
-Phil