From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bytemark.thekelleys.org.uk (bytemark.thekelleys.org.uk [IPv6:2001:41c8:51:46b:feff:ff:fe00:3310]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id AFBF421F2AC for ; Thu, 1 May 2014 11:35:20 -0700 (PDT) Received: from [31.121.236.48] (helo=[192.168.150.151]) by bytemark.thekelleys.org.uk with esmtpa (Exim 4.80) (envelope-from ) id 1WfvpC-0003Wy-Bv; Thu, 01 May 2014 18:35:14 +0000 Message-ID: <536293E0.6070508@thekelleys.org.uk> Date: Thu, 01 May 2014 19:35:12 +0100 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dave Taht , Jim Gettys , dnsmasq-discuss , "cerowrt-devel@lists.bufferbloat.net" References: <535EACCB.7090104@thekelleys.org.uk> <20140428232459.GA55372@redoubt.spodhuis.org> <535FA793.8020502@thekelleys.org.uk> <20140429205757.GA70801@redoubt.spodhuis.org> In-Reply-To: <20140429205757.GA70801@redoubt.spodhuis.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:35:21 -0000 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 >