New rc.d/named features for testing: auto-forwarding and wait on boot

From: Doug Barton <dougb_at_FreeBSD.org>
Date: Mon, 30 Mar 2009 23:04:17 -0700
Howdy,

There has been some discussion recently about the idea of adding an
option for the rc.d startup process to wait until name resolution
comes on line. (There is also room for a more general "wait for the
network to come on line" option, but I chose to focus on the named
version since my time is limited atm.)

The patch below has a fairly simple implementation of this feature
with 2 knobs, named_wait to enable it, and the optional
named_wait_host to specify what name to look up. It defaults to
localhost. Garrett Wollman gets credit for the rough strokes on this
one, though I refined it a bit (so blame for bugs goes to me).

For a long time now there has also been discussion about configuring
the local resolver to automatically forward to those name servers in
/etc/resolv.conf. This bit is a lot trickier, primarily because it
involves writing to /etc/namedb/ at boot time. However, the default is
to chroot the named process to /var/named/ so this should be
relatively safe.

The patch has an implementation of the feature that works for the few
networks I've tested it on. I feel that it is still a bit rough, but
it's ready for wider review. The basic idea is that we parse
/etc/resolv.conf for lines that begin with "nameserver" and try to
make use of the information. It writes a temp file to
/var/run/auto_forward.conf, then when it's done it compares the result
to what's in [/var/named]/etc/namedb/auto_forward.conf. If it's
different, the new one replaces the old. While it's being parsed, if
the local named is not the first nameserver line in /etc/resolv.conf
that is added, and if the new file differs from the existing one it
will be replaced too. This uses roughly the same logic as is used in
/sbin/dhclient-script.

The part where this has the ability to go wonky is in the named.conf
file. The patch has an update to that file with a _commented out_ line
that you can uncomment to enable the support (along with enabling it
in rc.conf of course). Where this _could_ go sideways is if you
uncomment that line in named.conf but then turn off the auto_forward
options. Fortunately, named supports 'include'ing empty files, so if
either there is no /etc/resolv.conf, or if the named_auto_forward
option is off and there is an existing /etc/namedb/auto_forward.conf
file, the script empties that file out.

I'm not thrilled with the idea of leaving an include of an empty file
lying around in the options { }; section of named.conf, which is why
it's commented out by default. However given the permissions it's no
_more_ dangerous than the named.conf file itself. The user could shoot
themselves in the foot if they disable the rc.conf option AND remove
/etc/namedb/auto_forward.conf without commenting the line in
named.conf, but that error is pretty obvious at named start-time.

There is a not-directly-related change in this patch as well that I've
had in the wings for a while to add named-checkconf to the pre-start
routine. Given that if the named_auto_forward* options are on we will
now be frobbing the conf behind the scenes I thought it was a good
idea to add this support now.

In addition to enabling auto_forward you can also enable
auto_forward_only which changes from the default 'forward first' to
(you guessed it) 'forward only'.

Comments and suggestions are welcome, but remember I said this was
rough. :)  BTW, you should be able to test this on RELENG_[67] too if
you really want to. I haven't tested the patch on those branches but
it should apply pretty cleanly, and it's not that much to add anyway.


Enjoy,

Doug

-- 

    This .signature sanitized for your protection
Received on Tue Mar 31 2009 - 04:11:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC