Date: Sat, 07 Jul 2012 16:45:57 -0700 From: Doug Barton <dougb@FreeBSD.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-security@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?) Message-ID: <4FF8CA35.7040209@FreeBSD.org> In-Reply-To: <0AFE3C4A-22DB-4134-949F-4D05BBFC4C6C@lists.zabbadoz.net> References: <CA%2BQLa9B-Dm-=hQCrbEgyfO4sKZ5aG72_PEFF9nLhyoy4GRCGrA@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <dougb@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FF8CA35.7040209>