FreeBSD 10: Unbound and LDNS replacing BIND

T

tanked

I must admit I was surprised this hasn't got more attention; does anyone know the reasons why BIND is being dropped?
 
It is mainly because BIND is a huge overkill as a local caching resolver when there is no need to have an authoritative DNS server at the same time. Unbound fits that role much better. You can install BIND from ports if you really need it.
 
Remember that BIND is just being removed from base. It can still be easily installed and updated from ports: dns/bind99. In fact, many people already did that to have the latest version.
 
Yes, I've already done that with the BIND port and selected the option to replace the base BIND; I also edited src.conf so that it wouldn't be rebuilt when rebuilding world.
 
Following from digging around (no pun intended) on an Ubuntu box I found that it uses DNSMasq as a local service to "resolve" and cache DNS requests. A little investigation revealed not only is it quite lightweight but also combines a DHCP server with internal DNS updates.

It turned out to be much simpler than BIND and ISC DHCP combination of dynamic updates and the developers report it supports around a thousand clients. Perfect for setting up your average SME network with about five lines to change in the configuration file.

BIND is great if you need all the bells and whistles but there are certainly lighter tools that perhaps are simpler and easier to administer but still get the job done.

My experience with DNSMasq did leave me feeling that for some simple basic setups BIND may be a tad over engineered.
 
Ok, stupid question.

I have installed BIND from ports but I can't find a proper rc startup script.

Code: 
named_enable="YES"
named_program="/usr/local/sbin/named"

#/etc/rc.d/named start

Code: 
/etc/rc.d/named: WARNING: /etc/mtree/BIND.chroot.dist missing,
/etc/rc.d/named: WARNING: chroot directory structure not updated
/etc/rc.d/named: WARNING: named chroot: /etc/namedb is a directory!
mount: /var/named/dev: No such file or directory
/etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev
devfs: open: /var/named/dev: No such file or directory
devfs: open: /var/named/dev: No such file or directory
cp: /var/named/etc/localtime: No such file or directory
cp: /var/named/etc/protocols: No such file or directory
cp: /var/named/etc/services: No such file or directory
rndc-confgen: create keyfile: file not found
Starting named.
/etc/rc.d/named: WARNING: failed to start named

#/usr/local/sbin/named just works fine. This is really irritating.
 
It sounds like the start up script is expecting that it can chroot(8) to /var/named but since you're on FreeBSD 10 that directory and the expected contents are not created by default.
 
kpa said:
Sounds like the start up script is expecting that it can chroot(8) to /var/named but since you're on FreeBSD 10 that directory and the expected contents are not created by default.
Click to expand...

Yes most probably. Any Idea how to fix that?

# ls /var/named/

Code: 
dev	etc	usr

# ls /etc/namedb/

Code: 
dynamic		master		named.conf	named.root	named.tgz	rndc.key	slave		working

# /etc/rc.d/named start

Code: 
/etc/rc.d/named: WARNING: /etc/mtree/BIND.chroot.dist missing,
/etc/rc.d/named: WARNING: chroot directory structure not updated
/etc/rc.d/named: WARNING: named chroot: /etc/namedb is a directory!
rndc-confgen: create keyfile: file not found
Starting named.
/etc/rc.d/named: WARNING: failed to start named

# mount

Code: 
.......
devfs on /var/named/dev (devfs, local, multilabel)
 
For some reason dns/bind99 refuses to run in a chroot environment. I am not sure if I am doing anything wrong since chroot configuration is the same like I have in other FreeBSD 9.X systems.

Specifying
Code: 
named_chrootdir=""
in rc.conf appears to solve the problem for now.
 
Wow, I found this page after seeing in the port configuration replace base is for 9.x or earlier so it got my interest. [ ¿Qué pasó? -- mod.]

It does seem that nowadays freebsd FreeBSD is more and more leaning to desktop features over server features.

Ok, some may say its there a sa port so deal with it, but its not quite that simple as various server software expects to find bind BIND files in the base directories, not a port. If the replace_base function still works in fbsd10 FreeBSD 10 then fair enough, if it doesn't there will be more problems with freebsd becoming incompatible with 3rd third-party software.
 
As someone who uses FreeBSD pretty much exclusively for servers, I'm perfectly happy with the change. The only reason to have BIND is if you really need a full featured authoritative server, and in 99% of our server installs, that isn't the case. I'm much happier with a light-weight, high performance resolver with the option to install BIND as a port if I'm actually building a DNS server. I can then using normal package/port functions to keep it up to date as well.

Regarding the problems mentioned above, it appears all the named_ flags were removed from /etc/defaults/rc.conf recently (and /etc/rc.d/named has gone) so hopefully things will be a bit smoother when 10.0 actually comes out. I would hope they make sure the port is updated before 10.0-RELEASE in order to detect 10.0+ and install a /usr/local/etc/rc.d/named script that works 'out of the box'.

Edit: In fact the port changes have already been done. I'm not sure what it means for chrooting in the future though.
Support FreeBSD 10.0.

On FreeBSD 10.0, all configuration is installed under
/usr/local/etc/namedb and installs its own rc script in
$PREFIX, which no longer support chroot installations.

LINKS and REPLACE_BASE options are not supported on 10.0
for obvious reasons.

Note for FreeBSD 9.x and earlier users, LINKS is no longer
the default option, though still supported.
Click to expand...

For any software that automates BIND configuration, I would hope it would be sensible enough to have options to specify the location of the configuration files and zone data files (unless the software is FreeBSD specific, these locations already vary depending on the OS as it is).
 
usdmatt said:
Edit: In fact the port changes have already been done. I'm not sure what it means for chrooting in the future though.
Click to expand...

It means that the port does not support running BIND in chroot any more. There was a long discussion in the mailing lists and the maintainer suggested that those who need the extra security should consider running BIND in a jail instead.

For me this is bad news because I could set up an authoritative DNS without having to install ANY third-party software.
 
gkontos said:
usdmatt said:
Edit: In fact the port changes have already been done. I'm not sure what it means for chrooting in the future though.
Click to expand...

It means that the port does not support running bind in chroot anymore. There was a long discussion in the mailing lists and the maintainer suggested that those who need the extra security should consider running bind in a jail instead.

For me this is bad news because I could set up an authoritative DNS without having to install ANY 3rd party software.
Click to expand...

Things get from bad to worse. It's as if they are trying to scare people away from the operating system.
 
Why don't you do something yourself? Like come up with a workable replacement for the chroot(8) system that is now missing? FreeBSD has always been a "patches accepted" system as long as those patches are good quality. It's so easy (and cheap) to talk from your comfy armchair and throw judgement at people who work very hard to keep FreeBSD alive. Get involved if you want to change things people!
 
kpa said:
Why don't you do something yourself? Like come up with a workable replacement for the chroot(8) system that is now missing? FreeBSD has always been a "patches accepted" system as long as those patches are good quality. It's so easy (and cheap) to talk from your comfy armchair and throw judgement at people who work very hard to keep FreeBSD alive. Get involved if you want to change things people!
Click to expand...

Yes that's the common reply I see to feedback I give. But what is special in this case is that the code already exists for a working chroot. There is no need to make a patch, simply they just readd the removed code. The good news is, it does seem one person on the mailing list is determined to fix it and he says he is making a patch for it.

In the meantime I wont be using FreeBSD 10 anyway, I am only just migrating some systems now to 9.2. So for me personally I will just hope that in two years or so the situation is different.
 
You must log in or register to reply here.
Back
Top