-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Doug Barton wrote: > 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 And of course, the patch: http://dougbarton.us/Downloads/rcd-named.diff - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEAREDAAYFAknRtX8ACgkQyIakK9Wy8PsdMQCeMDUoEp/waxAo2MtUql8CrYvo UF4AniOJwRHT4SfgEEgWqBgbZaANiXbo =4rKv -----END PGP SIGNATURE-----Received on Tue Mar 31 2009 - 04:17:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC