Replacing BIND with unbound

[Doug Barton]

On 8/21/2012 11:08 AM, Bjoern A. Zeeb wrote:
> On Tue, 21 Aug 2012, Doug Barton wrote:

>> Neither importing ldns nor removing BIND is going to have any effect on
>> the stub resolver library in libc.
> 
> Yes it does as if we are not carefull, we'll neither have a _proper_
> validating caching resolver but 4 different resolver libraries 3 of
> which needing crypto and only 2 with a well known support plan and
> only 2 with the same interface in base. 

Can you please enumerate what resolver libraries you're talking about,
because I don't understand what you're referring to here.

The way that I'm using the terms above:

1. A validating, caching resolver is a full server type thing, such as
BIND or Unbound.
2. The stub resolver library is (as currently implemented) part of libc,
and currently uses code from a completely separate import of the BIND
resolver library implementation. To be clear, removing src/contrib/bind9
won't affect that at all.
3. ldns _can_ be used to make a resolver library, but it does not have
to be. Under the plan that des and I have it would be used as the basis
of the dig-like tool called drill, and the host-alike tool that Vitaly
provided. It's also a dependency of Unbound, FWIW.

I have also said on numerous occasions that I don't think we should have
a _single_ validating resolver in the base at all, however I understand
that you think differently, which is why you raise the objection above.

> Can you see why Simon's question
> is important to not make the current problem worse? 

Of course I understand Simon's question. That's why I answered it. :)

> (rhetorical for
> you, Des will answer).  Can we make sure if we do this that things
> like portsnap and freebsd-update will not stop working (using the
> command line tools for example)? 

I've been testing Vitaly's host-alike tool, and haven't run into any
problems where the output is different. Obviously we would have to test
the dependencies before we pulled BIND out altogether. That's why we are
only contemplating doing this in HEAD, long before 10.0-RELEASE. It's
also worth pointing out that if we stick to the plan *cough* that we
have less than a year before 10-RELEASE, so getting started sooner
rather than later here is a good thing.

> Can we have a longer plan of where
> we want to be in a year, which parts we need from where and how to get
> them, and if we feel like it, add names to this?   It's strange that
> others in this thread have asked for it already, not just me yelling
> "stop".

But those things have already been discussed, most recently in this
thread. Really, you need to pay attention if you want to be involved. :)

Plan 0: Import ldns/drill/host-alike, remove BIND. Following which ...
Plan A: Allow user to choose from a list of validating resolvers at
install time, including at minimum Unbound and BIND.
Plan B: Import Unbound

Both Plans [AB] involve support for DNSSEC for whatever solutions we
make available to the users. IMO in order to be considered for inclusion
as a validating resolver the software has to support RFC 5011 rollovers,
which means that the difficult part of DNSSEC support is the
bootstrapping of the root trust anchor. I have an idea for how I want to
do that for BIND in the ports, but lately I have been thinking that it
might make more sense to write an rc.d script for the base that can do
this in a generic way at boot time. What is definitely *not* going to be
acceptable is a hard-coded "set and forget" scheme. We've already seen
that fail in another OS, and I don't want to repeat that mistake.

>> And if you have much larger plans for resolver libraries, especially
>> validating ones, it would be great if they were discussed IN PUBLIC, so
>> that those of us who know a little something about the topic can be
>> involved in the discussion BEFORE all the decisions are made, and all
>> the balls start rolling.
> 
> Do you understand the part about the wiki from above?  I can put an
> ACL on to exclude everyone but the secret cabal, having investigated
> days the last 18 months on the topic, talked to people on multiple
> continents, from different projects, ...  but I hadn't planned to ..
> and I am not the only one.  The fact that it's not written down is,
> as I said, things are only no longer totally nebulous since last week.

I'm sorry, I don't understand most of the paragraph above, but what it
sounds like is that you have been talking to people privately about what
you think this stuff should look like for 1 1/2 years. I think that's
great, but whatever private discussions you may have had don't give you
ownership of the problem. This is too important for any one person
(myself included) to deal with on their own. Whatever plans we may have
in this area need to be thoroughly discussed, IN PUBLIC, before
decisions are made, or actions are taken.

Not to mention that if the discussion had been public we could
potentially have benefited from the ability of many contributors being
able to make progress faster than 1 person trying to own the problem
solo (no matter how many continents they travel to).

> Given the only thing you currently want to do is getting rid of
> solving the problem of no longer maintaing named in base (which I
> think no one disagrees with per se) but do not want to invest in any
> of the other work,

That isn't true, and you know it isn't. I was the one who first raised
the issue of how important robust DNSSEC support is going to be to re@
(of which you are a member) years ago. I said at the time that I am not
only willing, but highly motivated to provide assistance in that area.
When you first mentioned your private discussions and plans for a
validating resolver in the base in that context a year or so ago, I
asked to be included at that time. You have chosen not to do that.

So, either you have an incredibly selective memory, or you are blatantly
lying in order to make me look bad. I find either option highly disturbing.

> I'd highly appreciate a lower noise level so
> others could in fact move forward in a more productive way. 

Um, no, I am definitely NOT going to lower the noise level on this. It's
too important.

> I could
> have started the wiki page rather than replying for example.

The fact that you chose one course of action over the other says more
about you than it does about me. :)

Doug

-- 

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
			-- Edward Everett Hale, (1822 - 1909)