Bug #1691

LAST CALL FOR TEST: Re: Suggestion: Removal of BIND from base / Import alternative DNS Library ldns / import dig replacement drill

Added by lentferj about 4 years ago. Updated almost 4 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Dear all,

I have lately been busy working on ripping BIND out from contrib and
base. I entirely remove BIND from contrib/ and moved the necessary files
for libresolv into lib/libc so libc still builds and works.

By removing BIND also all the related tools (host, nslookup, dig and
others) are gone. To still provide a tool to make DNS queries I decided
to put "drill" into base. This is a dig replacement that should be
option- and output-equal to BIND's dig.

This made it necessary to also import the alternative DNS Library ldns
(in which drill is included). In a second step ldns could also give us
the opportunity to also make libc independent for BINDs resolver as it
should provides it'S own resolver library. I guess all that needs to be
done is to interface the res_* stuff from BIND to ldns.

Enough words, necessary links:

http://www.nlnetlabs.nl/projects/ldns/
http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git

Please let me know what you think about his approach.

Jan

History

#1 Updated by dillon about 4 years ago

:Dear all,
:
:I have lately been busy working on ripping BIND out from contrib and
:base. I entirely remove BIND from contrib/ and moved the necessary files
:for libresolv into lib/libc so libc still builds and works.
:...
:
:This made it necessary to also import the alternative DNS Library ldns
:(in which drill is included). In a second step ldns could also give us
:the opportunity to also make libc independent for BINDs resolver as it
:should provides it'S own resolver library. I guess all that needs to be
:done is to interface the res_* stuff from BIND to ldns.
:
:Enough words, necessary links:
:
:http://www.nlnetlabs.nl/projects/ldns/
:http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git
:
:Please let me know what you think about his approach.
:
:Jan

I'm not sure about binary compatibility if the resolver is moved
out of libc (if I read that right) and into libldns. Or were you
intending on leaving the resolver in libc? I'm a little confused.

I fully agree with separating the resolver calls out from the BIND
contrib and putting them into libc natively, then disconnecting
BIND from the build and e.g. using pkgsrc to get its functionality.

-Matt
Matthew Dillon
<>

#2 Updated by lentferj about 4 years ago

Matthew Dillon schrieb:
>
> I'm not sure about binary compatibility if the resolver is moved
> out of libc (if I read that right) and into libldns. Or were you
> intending on leaving the resolver in libc? I'm a little confused.

This is not part of this patch-set. I moved BINDs resolver into
libc/resolv, libc/nameser etc. So libc is basically unchanged.

Moving resolver to libldns is an idea that needs a lot deeper investigation.

> I fully agree with separating the resolver calls out from the BIND
> contrib and putting them into libc natively, then disconnecting
> BIND from the build and e.g. using pkgsrc to get its functionality.

That is exactly what this patchset does.

Jan

#3 Updated by c.turner about 4 years ago

Chris Turner wrote:
>
> (e.g. doesn't this just substitute one lesser known 3rd party software
> in contrib for another one, embedded into libc)

p.s: I fully admit being too lazy to read over the patch / compare /
etc. I admire your hackitude!

#4 Updated by c.turner about 4 years ago

Jan Lentfer wrote:
> This made it necessary to also import the alternative DNS Library ldns
> (in which drill is included). In a second step ldns could also give us
> the opportunity to also make libc independent for BINDs resolver as it
> should provides it'S own resolver library. I guess all that needs to be
> done is to interface the res_* stuff from BIND to ldns.

Don't know anything about this library, save from what I could grok from
a quick look.. what's the advantage of using it, instead of just ripping
out the minimum to support client lookups + userland from the ISC code?

(e.g. doesn't this just substitute one lesser known 3rd party software
in contrib for another one, embedded into libc)

#5 Updated by lentferj about 4 years ago

That is what I did for now. The resolver stuff necessary for libc from
BIND was moved into lib/libc/resolv lib/libc/nameser and so on.
Replacing the resolver with ldns would be a possible second (or 3rd
or..) step I'd like to discuss to be entirely independent of BIND's code
base - of course by introducing another dependency elsewhere. From what
I have heard this is the way OpenBSD is going (irc rumours).
ldns seems more lightweight and it is *just* a DNS library - whereas
BIND's libresolv is not a standalone library but comes bundled with BIND
only.

Well, it doesn't atm, because it is not part of this patch-set :-).
But that is exactly what has to be discussed in the future. At the
moment ldns is only use for drill (the dig replacement) in my patch-set,
nothing else. But I think (someone else with a lot more knowledge about
libc and resolver stuff has to verify this) it would open the door for
us to switch the resolver part of our libc to ldns from BIND.

Jan

#6 Updated by lentferj about 4 years ago

On Wed, 10 Mar 2010 10:27:44 +0100, Mathieu Launay
<> wrote:
> First, I would like to say that I am not reluctant to changes, but the
> fact is I like to have a DNS recursive server in base because you can
> "bootstrap" the box you install from nothing to a fully functionnal
> internet access, without having a local DNS server or knowing an open
> resolver (at least open for you).
>
> Why do not put unbound (from NLNet labs) into base to serve this
> purpose?

OpenBSD has picked NSD for that.
http://www.nlnetlabs.nl/projects/nsd/

Anyway I am open for that discussion also. But anyway you could easily
install anything you like from pkgsrc.

Jan

#7 Updated by check+kz44a100rscmc1i2 about 4 years ago

Jan Lentfer wrote:
> Mathieu Launay wrote:
> > Why do not put unbound (from NLNet labs) into base to serve this
> > purpose?
>
> OpenBSD has picked NSD for that.
> http://www.nlnetlabs.nl/projects/nsd/
>
> Anyway I am open for that discussion also. But anyway you could easily
> install anything you like from pkgsrc.

Not that my opinion really matters, but ...

As long as you don't pick djbdns, I'm happy with anything. :-)

Best regards
Oliver

#8 Updated by ftigeot about 4 years ago

Oliver Fromme wrote:
> Jan Lentfer wrote:
> > Mathieu Launay wrote:
> > > Why do not put unbound (from NLNet labs) into base to serve this
> > > purpose?
> >
> > OpenBSD has picked NSD for that.
> > http://www.nlnetlabs.nl/projects/nsd/
> >
> > Anyway I am open for that discussion also. But anyway you could easily
> > install anything you like from pkgsrc.
>
> Not that my opinion really matters, but ...
>
> As long as you don't pick djbdns, I'm happy with anything. :-)

AFAIK, djbdns doesn't implement DNSSEC, so there is a good chance it will
slowly die in the future.

Root servers should begin to serve a signed .arpa zone beginning on march
15...

#9 Updated by mureninc about 4 years ago

On 11 March 2010 20:00, Francois Tigeot <> wrote:
> Oliver Fromme wrote:
>> Jan Lentfer wrote:
>>  > Mathieu Launay wrote:
>>  > > Why do not put unbound (from NLNet labs) into base to serve this
>>  > > purpose?
>>  >
>>  > OpenBSD has picked NSD for that.
>>  > http://www.nlnetlabs.nl/projects/nsd/
>>  >
>>  > Anyway I am open for that discussion also. But anyway you could easily
>>  > install anything you like from pkgsrc.
>>
>> Not that my opinion really matters, but ...
>>
>> As long as you don't pick djbdns, I'm happy with anything.  :-)
>
> AFAIK, djbdns doesn't implement DNSSEC, so there is a good chance it will
> slowly die in the future.
>
> Root servers should begin to serve a signed .arpa zone beginning on march
> 15...

Yet another “BSD is dying” prediction? :-p

http://www.google.com/search?q=dnssec+site:cr.yp.to
http://cr.yp.to/talks.html#2009.08.10
http://cr.yp.to/talks/2009.08.10/slides.pdf

C.

#10 Updated by lentferj about 4 years ago

[...]

I have rebased my work on the latest master.
http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git

It will take some time for me to document the upgrade path to BIND from
pkgsrc for those people actually running a BIND based Nameserver. When I
am finished with that and noone strongly objects in the meantime I will
issue a "HEADS UP" on users@ and kernel@ and push it in.

So, take your chance and test :-)

Jan

#11 Updated by pavalos about 4 years ago

On Thu, 08 Apr 2010 06:16:12 +0200, Jan Lentfer <>
wrote:
> Jan Lentfer schrieb:
>> Dear all,
>>
>> I have lately been busy working on ripping BIND out from contrib and
>> base. I entirely remove BIND from contrib/ and moved the necessary
files
>> for libresolv into lib/libc so libc still builds and works.
> [...]
>

I don't like the idea of having contrib source somewhere other than
contrib/. I'm out of the country with barely functioning network
connectivity so I'm unable to view your changes. Apparently you are moving
BIND's resolver library sources into src/lib/libc/. That seems strange to
me. Also, what are we gaining by switching from BIND's dns tools to
someone else's?

--Peter

#12 Updated by lentferj about 4 years ago

On Wed, 07 Apr 2010 18:57:00 -1000, Peter Avalos <>
wrote:

moving
> BIND's resolver library sources into src/lib/libc/. That seems strange
to
> me. Also, what are we gaining by switching from BIND's dns tools to
> someone else's?

Yes, I am moving BIND's resolver lib to libc, as any of the other BSDs are
doing it (which I admit is a weak reason by itself). The problem I see atm
is that if we provide BIND in base it should be actual, actually always
latest patch level and it seems to me we lack the man power to achieve
this. Otherwise we only carry BIND around with us to have the resolver lib,
because BIND itself and related tools are bareley usable (at least from a
security poing of view) because they are out of date.
When I updated BIND we still had 9.3 in base, which was EOL for more than
a year at that time. I choose to update to 9.5.2 (and not 9.6) because the
directory layout remained the same in comparison to 9.3, so the upgrade
seem to be less painful (still it was) but would at least provide us with a
maintained version of BIND.

So I find it the better approach to only keep what is absolutley necessary
and let people use the Nameserver software of their choice from pkgsrc.

Regarding import of ldns/drill: This is a comprimise. Most people (on IRC
that is) seem to be happy with removing BIND but didn't want to pay the
price of losing host and friends. ldns seems to be a lot more lightweight
then BIND and has a strong focus on DNSSEC, drill is just a host
replacement to keep those happy that demand a dns query tool.

Jan

#13 Updated by db about 4 years ago

Hi,

I would prefer it if someone took the time to maintain bind, rather than
throwing it out. I think bind is still the most deployed dns-server, and it
is nice to be able to use it, without dealing with pkgsrc etc. I also think
people are very much used to tools like 'dig' and friends - I'm sure I can
get used to drill, if it can do all the things dig can, but I'd rather not.

However, if nobody is willing to maintain Bind, I think it is much better to
throw it out, than to have it rotting in our base, possibly having security
issues, due to lack of testing.

Great work, and thank you for your interesst in this issue Jan!

Cheers,

DB.

Jan Lentfer <> skrev følgende den 4/8/10 9:32 AM:

> On Wed, 07 Apr 2010 18:57:00 -1000, Peter Avalos <>
> wrote:
>
>> I don't like the idea of having contrib source somewhere other than
>> contrib/. I'm out of the country with barely functioning network
>> connectivity so I'm unable to view your changes. Apparently you are
> moving
>> BIND's resolver library sources into src/lib/libc/. That seems strange
> to
>> me. Also, what are we gaining by switching from BIND's dns tools to
>> someone else's?
>
> Yes, I am moving BIND's resolver lib to libc, as any of the other BSDs are
> doing it (which I admit is a weak reason by itself). The problem I see atm
> is that if we provide BIND in base it should be actual, actually always
> latest patch level and it seems to me we lack the man power to achieve
> this. Otherwise we only carry BIND around with us to have the resolver lib,
> because BIND itself and related tools are bareley usable (at least from a
> security poing of view) because they are out of date.
> When I updated BIND we still had 9.3 in base, which was EOL for more than
> a year at that time. I choose to update to 9.5.2 (and not 9.6) because the
> directory layout remained the same in comparison to 9.3, so the upgrade
> seem to be less painful (still it was) but would at least provide us with a
> maintained version of BIND.
>
> So I find it the better approach to only keep what is absolutley necessary
> and let people use the Nameserver software of their choice from pkgsrc.
>
> Regarding import of ldns/drill: This is a comprimise. Most people (on IRC
> that is) seem to be happy with removing BIND but didn't want to pay the
> price of losing host and friends. ldns seems to be a lot more lightweight
> then BIND and has a strong focus on DNSSEC, drill is just a host
> replacement to keep those happy that demand a dns query tool.
>
> Jan

#14 Updated by dillon about 4 years ago

What we are doing is separating the client-side of the resolver
used by libc from the DNS server. De-integrating the two, that is.

This is something we need to do. It will make it a whole lot easier
to make multiple DNS server options available without risking breaking
the system libraries.

-Matt

#15 Updated by qhwt+dfly about 4 years ago

Hi.

On Thu, Apr 08, 2010 at 06:16:12AM +0200, Jan Lentfer wrote:
> I have rebased my work on the latest master.
> http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git

Although it shares the prefix with rndc or rndc-confgen, rndcontrol
has nothing to do with ISC BIND :) Please be sure to unstage it from
22a6bbb1, and remove any rndcontrol* lines from 7c704b13, before
pushing it to crater.

Cheers.

#16 Updated by lentferj about 4 years ago

Absolutley right and I thought I fixed that a while ago, must have
slipped in again. Thanks for reviewing!

Jan

#18 Updated by lentferj about 4 years ago

Ah, ok, 2nd look ist always good. Got it, I am also deleting the source
files of rndcontrol in 22a6bbb1. Will fix that. Thanks again.

Jan

#19 Updated by lentferj about 4 years ago

On Fri, 09 Apr 2010 06:22:30 +0200, Jan Lentfer <>
wrote:
> Jan Lentfer schrieb:
>> YONETANI Tomokazu schrieb:
>>> Hi.
>>>
>>> On Thu, Apr 08, 2010 at 06:16:12AM +0200, Jan Lentfer wrote:
>>>
>>>> I have rebased my work on the latest master.
>>>> http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git
>>>>
>>>
>>> Although it shares the prefix with rndc or rndc-confgen, rndcontrol
>>> has nothing to do with ISC BIND :) Please be sure to unstage it from
>>> 22a6bbb1, and remove any rndcontrol* lines from 7c704b13, before
>>> pushing it to crater.
>>>
>> I knew I reverted that already :-)
>>
http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/blobdiff/178aaca24426faa6b444c36df0825ddb5a26b69a..598697de932f24b594fd71d079160735516ee9a4:/Makefile_upgrade.inc
>>
>>
> Ah, ok, 2nd look ist always good. Got it, I am also deleting the source
> files of rndcontrol in 22a6bbb1. Will fix that. Thanks again.

Ok, I removed the last commit and edited 7c704b13 to contain that. Also
reverte the removal of rndcontrol from 22a6bbb1. I would be very thankful
if you gut look at it again.

TIA

Jan

#20 Updated by mathieu about 4 years ago

Hello all,

On Thu, 08 Apr 2010 at 06:16 +0200, Jan Lentfer wrote :
> > I have lately been busy working on ripping BIND out from contrib and
> > base. I entirely remove BIND from contrib/ and moved the necessary files
> > for libresolv into lib/libc so libc still builds and works.

As said on IRC, I would be very pleased if you could keep a recursive
DNS server either in base or added to the distribution from pkgsrc, to
have a setup which is not dependant from an external DNS server.

I see the typical case like this:
- install DragonFly
- setup the network interface(s)
- setup the default route
- echo "${dns-server}_enable=YES" >> /etc/rc.conf
- start it

then you have full internet connectivity without relying on DNS provided
by your ISP (or corp etc.).

For this matter, I propose to use Unbound[1] from NLNet Labs, a choice
which is coherent with the use of ldns, and follows the "one tool for
one use" rule (it is a recursive and caching DNS resolver only).

[1] http://www.unbound.net/
--
/~\ The ASCII Mathieu Launay
\ / Ribbon Campaign <>
X Against HTML
/ \ Email! BFC6 F9FC 4993 8963 50EC 736A 795D E1C5 D681 2BAE

#21 Updated by qhwt+dfly about 4 years ago

On Fri, Apr 09, 2010 at 08:23:59AM +0200, Jan Lentfer wrote:
> Ok, I removed the last commit and edited 7c704b13 to contain that. Also
> reverte the removal of rndcontrol from 22a6bbb1. I would be very thankful
> if you gut look at it again.

Thanks, I've done a full buildworld/installworld/upgrade onto one of
my laptops and it went flawlessly.

One thing I miss from `host' command is its terseness in the output.

$ host www.dragonflybsd.org
www.dragonflybsd.org is an alias for leaf.dragonflybsd.org.
leaf.dragonflybsd.org has address 216.240.41.26
leaf.dragonflybsd.org mail is handled by 10 leaf.dragonflybsd.org.

`host -v' gives you a similar output as drill does. Drill does have
-Q(quiet) option, but it's too shy to show me anything no matter what
it finds or not, not even the return code :)
$ drill -Q www.dragonflybsd.org; echo $?
0
$ drill -Q www.dargonflybsd.org; echo $?
0

I can write an alias or a shell function to cope with the verboseness,
but maybe we could modify the behavior of -Q to show something rather
than nothing.

Cheers.

#22 Updated by aoiko about 4 years ago

YONETANI Tomokazu wrote:
> On Fri, Apr 09, 2010 at 08:23:59AM +0200, Jan Lentfer wrote:
>> Ok, I removed the last commit and edited 7c704b13 to contain that. Also
>> reverte the removal of rndcontrol from 22a6bbb1. I would be very thankful
>> if you gut look at it again.
>
> Thanks, I've done a full buildworld/installworld/upgrade onto one of
> my laptops and it went flawlessly.
>
> One thing I miss from `host' command is its terseness in the output.
>
> $ host www.dragonflybsd.org
> www.dragonflybsd.org is an alias for leaf.dragonflybsd.org.
> leaf.dragonflybsd.org has address 216.240.41.26
> leaf.dragonflybsd.org mail is handled by 10 leaf.dragonflybsd.org.
>
> `host -v' gives you a similar output as drill does. Drill does have
> -Q(quiet) option, but it's too shy to show me anything no matter what
> it finds or not, not even the return code :)
> $ drill -Q www.dragonflybsd.org; echo $?
> 0
> $ drill -Q www.dargonflybsd.org; echo $?
> 0
>
> I can write an alias or a shell function to cope with the verboseness,
> but maybe we could modify the behavior of -Q to show something rather
> than nothing.

Perhaps we can provide a 'host' script that generates mostly-compatible
output using drill in the background?

Just a thought,
Aggelos

#23 Updated by justin about 4 years ago

On Sun, April 11, 2010 10:45 pm, Aggelos Economopoulos wrote:

> Perhaps we can provide a 'host' script that generates mostly-compatible
> output using drill in the background?

Me nitpicking: What happens if people install BIND from pkgsrc? Which
'host' would run? I think it would the native version, which would have
strange output. If it was changed to the pkgsrc version, the change in
output style may confuse things.

My thought is that a behind-the-scenes change that makes it look like host
or dig are still present, but really aren't, may lead to more overall
confusion than having bind need to come from pkgsrc; that may be the
preferred solution.

#24 Updated by lentferj about 4 years ago

It should be possible to hack drill.c to add another option like '-h'
that provides a host like output I'd guess. The "-Q" option does not
look very overthough, so :-)

Jan

#25 Updated by lentferj about 4 years ago

Jan Lentfer schrieb:

> It should be possible to hack drill.c to add another option like '-h'
> that provides a host like output I'd guess. The "-Q" option does not
> look very overthough, so :-)

I guess '-Q' is meant to be used with the file options like '-w' and
nothing else.

Jan

#26 Updated by ano about 4 years ago

"-h" = "help"

#27 Updated by aoiko about 4 years ago

Justin C. Sherrill wrote:
> On Sun, April 11, 2010 10:45 pm, Aggelos Economopoulos wrote:
>
>> Perhaps we can provide a 'host' script that generates mostly-compatible
>> output using drill in the background?
>
> Me nitpicking: What happens if people install BIND from pkgsrc? Which
> 'host' would run? I think it would the native version, which would have
> strange output. If it was changed to the pkgsrc version, the change in
> output style may confuse things.

Beh. There could be scripts using host to do nontrivial queries I guess.
Scrap that idea.

> My thought is that a behind-the-scenes change that makes it look like host
> or dig are still present, but really aren't, may lead to more overall
> confusion than having bind need to come from pkgsrc; that may be the
> preferred solution.

Agreed. Another idea would be to make host an alias (so it wouldn't
matter for scripts) for

if test -z `which host`; then
echo "DragonFly no longer includes the BIND tools in the base
system"
echo "You need to install BIND from pkgsrc"
echo "Alternatively, you can use drill(1)"
else
exec `which host`
fi

in /etc/profile (and the csh equivalent). OTOH I'm not sure we want to
add stuff like that when we remove things from base. Dunno.

Are we going to install the BIND package by default?

Aggelos

Also available in: Atom PDF