From owner-freebsd-stable@FreeBSD.ORG Fri Dec 6 23:31:29 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 E965A172; Fri, 6 Dec 2013 23:31:28 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 790131D53; Fri, 6 Dec 2013 23:31:28 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id D88C82383B6; Fri, 6 Dec 2013 23:31:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A54B3160446; Fri, 6 Dec 2013 23:39:13 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 41E8F160436; Fri, 6 Dec 2013 23:39:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1238AB57011; Sat, 7 Dec 2013 10:31:10 +1100 (EST) To: Mark Felder From: Mark Andrews 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> Subject: Re: BIND chroot environment in 10-RELEASE...gone? In-reply-to: Your message of "Fri, 06 Dec 2013 17:01:56 -0600." <1386370916.5659.56527093.3A6A1DF1@webmail.messagingengine.com> Date: Sat, 07 Dec 2013 10:31:10 +1100 Message-Id: <20131206233110.1238AB57011@rock.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mx.ams1.isc.org 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: Fri, 06 Dec 2013 23:31:29 -0000 In message <1386370916.5659.56527093.3A6A1DF1@webmail.messagingengine.com>, Mar k Felder writes: > 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. A validating resolver still gets answers from unsigned zones. There really isn't much of a cost beyond that of setting it up. I don't think I've needed to touch the validating side of my recursive servers since the root zone was signed. > I'm a small fish working in a small ISP, and I admin the DNS servers for > maybe 5000 zones. I have zero DNSSEC. In 2014 I expect to maybe have one > zone (ours) with DNSSEC. I do not even expect our customers to request > or understand DNSSEC by 2020 -- not even the local banks and credit > unions we are authoritative for. I expect as DANE support rolls out in browsers that will change quicker than you expect. As a ISP you should be encouraging your users to do best practice which includes signing their zones. > On the other hand, running a new daemon on all of our servers -- many of > them lightweight VMs -- is likely out of the question; we're time > constrained as-is. (My DNS servers are on a trusted network; if they're > in our network we have a whole host of different problems. If they're on > the server itself nothing can be trusted; they'd just hijack the network > stack anyway.) The DNS is very much set and forget for small servers. It's when you have millions of recursive clients or millions of different queries that it gets interesting as you hit capacity issues. > Anyway, this is just my two cents; the idea is noble and > well-intentioned but I don't think it will gain traction. Security is > always an uphill battle. :-( I'm honestly more worried about BGP route > hijacking / MiTM than DNS MiTM attacks. I appreciate your thoughts and > insight, though. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org