From owner-freebsd-security@FreeBSD.ORG Sat Jul 7 23:45:58 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id D72FD106566B; Sat, 7 Jul 2012 23:45:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5DB8C14DB28; Sat, 7 Jul 2012 23:45:58 +0000 (UTC) Message-ID: <4FF8CA35.7040209@FreeBSD.org> Date: Sat, 07 Jul 2012 16:45:57 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4FF2E00E.2030502@FreeBSD.org> <86bojxow6x.fsf@ds4.des.no> <89AB703D-E075-4AAC-AC1B-B358CC4E4E7F@lists.zabbadoz.net> <4FF8C3A1.9080805@FreeBSD.org> <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> In-Reply-To: <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 23:45:59 -0000 On 07/07/2012 16:34, Bjoern A. Zeeb wrote: > On 7. Jul 2012, at 23:17 , Doug Barton wrote: > >> On 07/07/2012 14:16, Bjoern A. Zeeb wrote: >>> >>> On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote: >>> >>>> Doug Barton writes: >>>>> The correct solution to this problem is to remove BIND from the base >>>>> altogether, but I have no energy for all the whinging that would happen >>>>> if I tried (again) to do that. >>>> >>>> I don't think there will be as much whinging as you expect. Times have >>>> changed. >>>> >>>> I'm willing to import and maintain unbound (BSD-licensed validating, >>>> recursive, and caching DNS resolver) if you remove BIND. >>> >>> I'd object to it. Trading one for another without gaining anything does >>> not help us much. >> >> Au contraire. It solves the problem of BIND release cycles not matching >> up with ours. This is a very important problem to solve. > > Right and unbound et al are better? Bind at least gives us long term > support releases these days. We just need to make sure we pick them > for releases. > > >> I've already written at length as to what I think the dream solution is, >> but we don't have anyone willing to code that yet, and even if we did, >> there is no guarantee that we'd get the buy-in to make it happen. In >> addition to being a good first step, doing this for DNS will also help >> us shake out the exact issues you allude to below. >> >>> Don't get me wrong I have both running for years and even maintain patches >>> for unbound for 2 years now for functionality they do not provide, which >>> named happily gives me. >> >> Other than authoritative DNS, what features does unbound lack that you want? > > DNS64 as a start. Personally I would classify that as a highly-specialized request, and would point you to the bind* ports. I acknowledge that others may have a different view. > I don't care about the auth. support really with what is > in base; it is nice that it comes for free and it is nice, that I'll not > run into port 53 conflicts on single-IP systems .... but the only thing we > really need is a caching resolver. It's good that we agree on that bit at least. >>> If you want to do this, I would prefer a properly laid out action plan >>> as the import is by far the easiest but the integration into various >>> parts of the system is harder. >> >> BIND in the base today comes with a full-featured local resolver >> configuration, which I'm confident that Dag-Erling can do for unbound >> (and which I would be glad to assist with if needed). Other than that, >> what integration are you concerned about? > > startup scripts; Obviously that would be part of the import, and it should go without saying that I'm glad to help with that as well, if my help is needed. > resolvconf, There is code in the rc.d/named script that handles this which can be copied pretty much verbatim (or possibly factored out into its own script). Other than that I'm not aware of any BIND integration for this. > named.conf -> unbound.conf guides for our users, ACK > and not solving the issue that we really want a DNSSEC enabled caching > resolver with libc APIs for applications to use DNSSEC in base that people > are working on. We will probably need a crpyto and most likely also an > external dnssec speaking resolver library for this in the future, but > which of the 7 it will be we don't know yet. Yes, but that's a totally different issue. Also re DNSSEC integration in the base, I've stated before that I believe very strongly that any kind of hard-coding of trust anchors as part of the base resolver setup is a bad idea, and should not be done. We need to leverage the ports system for this so that we don't get stuck with a scenario where we have stale stuff in the base that is hard for users to upgrade. I have a POC for this for BIND that I need to finish, and I'm confident that something similar for unbound would not be difficult. Doug -- This .signature sanitized for your protection