DragonFlyBSD

: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 
                    <dillon@backplane.com>

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

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!

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)

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

On Wed, 10 Mar 2010 10:27:44 +0100, Mathieu Launay
<mathieu@breatheless.net> 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

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

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...

On 11 March 2010 20:00, Francois Tigeot <ftigeot@wolfpond.org> 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.

[...]

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

On Thu, 08 Apr 2010 06:16:12 +0200, Jan Lentfer <Jan.Lentfer@web.de>
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

On Wed, 07 Apr 2010 18:57:00 -1000, Peter Avalos <pavalos@theshell.com>
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

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 <Jan.Lentfer@web.de> skrev følgende den 4/8/10 9:32 AM:

On Wed, 07 Apr 2010 18:57:00 -1000, Peter Avalos <pavalos@theshell.com>
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

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

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.

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

Jan

I knew I reverted that already :-)
http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/blobdiff/178aaca24426faa6b444c36df0825ddb5a26b69a..598697de932f24b594fd71d079160735516ee9a4:/Makefile_upgrade.inc

Jan

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

On Fri, 09 Apr 2010 06:22:30 +0200, Jan Lentfer <Jan.Lentfer@web.de>
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

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¹ 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 <mathieu@breatheless.net>
X Against HTML
/ \ Email! BFC6 F9FC 4993 8963 50EC 736A 795D E1C5 D681 2BAE

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.

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

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.

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

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

"-h" = "help"

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