From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B295A21F118 for ; Wed, 30 Apr 2014 10:26:23 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so1142014wes.30 for ; Wed, 30 Apr 2014 10:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=0R3fvJUJY/7Px8UDOdBAc2f5fOvj2aUcnucbzSvt+dA=; b=OqshJUWocNNHjKzSeUCSq29pJ+fzNEJCTHxHBA95Eeet3Zuothm9JqQRDBf/WUWDSR GtI82Th/Jg5yjqTt7y5l8msxQdhp96dGpguXCZ66n3B7QcVZFQl8E5LUOvysOi4mSbIA 4gtfF7GpJ3ptubYOJV7+36wX9P5ZS4hgsE+RZqO/WnNCs/A8k46r4WN7tGALptR5cLHq T1C9P9eVZkBpcN7ctAX+WkoZgkiM8AwokXQa8knqbDeTxAy7euDjiwnNwxKbSQnwzDaN aq6fXBlAmAQprG3wqXVeRjovcdQZLEFnMdWKk9ACXcSzmcs24fzXNT4OwyKXBsFtqIiw Bs+Q== MIME-Version: 1.0 X-Received: by 10.194.9.8 with SMTP id v8mr3820475wja.53.1398878781495; Wed, 30 Apr 2014 10:26:21 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Wed, 30 Apr 2014 10:26:21 -0700 (PDT) In-Reply-To: <20140429205757.GA70801@redoubt.spodhuis.org> References: <535EACCB.7090104@thekelleys.org.uk> <20140428232459.GA55372@redoubt.spodhuis.org> <535FA793.8020502@thekelleys.org.uk> <20140429205757.GA70801@redoubt.spodhuis.org> Date: Wed, 30 Apr 2014 10:26:21 -0700 Message-ID: From: Dave Taht To: Simon Kelley , Dave Taht , Jim Gettys , dnsmasq-discuss , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 30 Apr 2014 17:26:24 -0000 On Tue, Apr 29, 2014 at 1:57 PM, 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". > > 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 --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article