From owner-freebsd-stable@FreeBSD.ORG Sat Dec 7 02:19:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6738A3D7; Sat, 7 Dec 2013 02:19:08 +0000 (UTC) Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0BC3617B4; Sat, 7 Dec 2013 02:19:07 +0000 (UTC) Received: from sponge.es.net ([IPv6:2601:9:2c80:35::2222]) (authenticated bits=0) by burnttofu.net (8.14.7/8.14.5) with ESMTP id rB72J3TP030536 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 6 Dec 2013 21:19:04 -0500 (EST) (envelope-from michael@rancid.berkeley.edu) Message-ID: <52A28592.1000200@rancid.berkeley.edu> Date: Fri, 06 Dec 2013 18:18:58 -0800 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mark Felder , Mark Andrews Subject: Re: BIND chroot environment in 10-RELEASE...gone? References: <529D9CC5.8060709@rancid.berkeley.edu> <20131204095855.GY29825@droso.dk> <20131205193815.05de3829de9e33197fe210ac@getmail.no> <20131206143944.4873391d@suse3> <20131206220016.BADCAB556F4@rock.dv.isc.org> <1386367748.17212.56515229.7C50AFEB@webmail.messagingengine.com> <20131206223300.89253B55861@rock.dv.isc.org> <1386370916.5659.56527093.3A6A1DF1@webmail.messagingengine.com> In-Reply-To: <1386370916.5659.56527093.3A6A1DF1@webmail.messagingengine.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]); Fri, 06 Dec 2013 21:19:05 -0500 (EST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 02:19:08 -0000 On 12/06/13 15:01, Mark Felder wrote: > On Fri, Dec 6, 2013, at 16:33, Mark Andrews wrote: >> >> In message >> <1386367748.17212.56515229.7C50AFEB@webmail.messagingengine.com>, Ma >> rk Felder writes: >>> On Fri, Dec 6, 2013, at 16:00, Mark Andrews wrote: >>>> >>>> But they should all be running a resursive validating resolver on >>>> every box. >>>> >>> >>> Are you *really* suggesting that I should run a recursive validating >>> server on every single server I admin? >> >> I'm suggesting that it should be run on *every* machine in the >> world, until all the applications that use data from the DNS have >> been upgraded to validate the data they get from the DNS, need to >> be be running a validating resolver. >> >> MiTM attacks happen all the time in the DNS. >> >> For mobile devices I would say "Don't leave home without one" to >> use a well know slogan. >> > > In a world where every zone is signed (DNSSEC) I might agree, but what's > preventing your traffic from being a victim of a MITM attack when 99% of > the internet doesn't have DNSSEC deployed? Having a local resolver > doesn't improve your security in a statistically significant way. Actually, you have it backwards. Think of it this way: Not every website uses https, but it is VERY useful and important that 100% of the browsers out there support https. That way, the client/server interactions that need https can get https. If I want clients to access my site over https, I simply have to put a cert on my website and configure it to force the clients to do the right thing. What we need is 100% adoption of validation, regardless of the percentage of zones actually signed. That way, if I choose to sign my zone, I know that everyone will actually be validating it. Until we have validating stub resolvers (and Casper seems like a promising way to do that), having validating daemons does provide that blanket client support that we need. michael