From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0588C21F248 for ; Tue, 29 Apr 2014 13:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201312; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=l9aN5MOIUJ5LjQLrrTjHlOb3FV9IY98PGLfVOH9tzrk=; b=jHmBwGnyzhlXk0aOr1f9kSgO+4T3mWo56bPkYQrGNUdbOniIzIqGFh3sPO71gOGaWLWYKQVVYKEMjE65Zi/rGNx/25f9kg18RVy8nUGzFsgCiQmYkQK44dnzwkPWqUC/oLBBB7HLmIgx880x8Gfzcd67ihaCuPnUMw1g0l93neUtFzqa1V7Jce0XmD2uawJncRis7+tcE6QcHeBj; Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1WfF6E-000IS3-Hv; Tue, 29 Apr 2014 20:57:58 +0000 Date: Tue, 29 Apr 2014 16:57:57 -0400 From: Phil Pennock To: Simon Kelley Message-ID: <20140429205757.GA70801@redoubt.spodhuis.org> Mail-Followup-To: Simon Kelley , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535FA793.8020502@thekelleys.org.uk> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x3903637F.asc Cc: dnsmasq-discuss , "cerowrt-devel@lists.bufferbloat.net" 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: Tue, 29 Apr 2014 20:58:04 -0000 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