
I've been a bit behind with the ISC DHCP v3 package of late. I've had a
package of 3.1.0 for a few months, but I'm becoming more and more reluctant
to make uploads of this package without giving it some rudimentary testing.
Real life has been demanding of late, so I haven't had a chance to do that
testing. Nothing's gone wrong with the package to date, I just feel
negligent not giving it some basic testing before throwing it out there.
So I chucked a spare QFE card in my workstation
brutus, put
unstable on the second hard drive, installed Debian unstable on the spare
10G partition of Sarah's old PowerBook, and lashed the two together with a
bit of CAT-5, and voila, instant DHCP client/server testbed.
So now that I'd verified that version 3.1.0 wasn't blatantly broken, I could
have a fiddle with the new support for option 119 (domain-search) that has
people at work very excited. I spent a bit of time off on a wild goose chase
trying to figure out how to configure the DHCP server for this new option
before I realised it was as simple as
option domain-search "foo bar
baz"; and then made the necessary tweaks to
dhclient-script.
I'm figuring that since one of the blokes who wrote
the RFC works at Apple, and
since Leopard supports option 119, the way they're doing it in Leopard must
be approximately correct, so I've altered the behaviour of the DHCP client
accordingly.
All of this assumes you're
not using
resolvconf.
Prior to 3.1.0, if you had the
domain-name option set, the
/etc/resolv.conf created by
dhclient-script would set the
search directive to the domain name. With 3.1.0, I've decided to
make this set the
domain option instead. The resolver behaviour
remains the same, as best as I can determine.
With 3.1.0, if the
domain-search option is set, then the
search directive is set to this. If the
domain-name option
is set, this is prepended to the list of domains in the
domain-search option. This is consistent with what MacOS X 10.5
(Leopard) does. I'm not sure what Windows does (nor what version started
honouring the
domain-search DHCP option)), and since it doesn't
have an
/etc/resolv.conf equivalent, it's a bit hard to test. I'm
going to hazard a guess and hope that since the other bloke who wrote the
RFC works for Microsoft, that maybe, just maybe, Windows and MacOS X at
least behave the same way.
Currently, if
resolvconf is in use, you get the old
behaviour whereby the
search directive is populated with the
contents of the
domain-name option, and the
domain-search
option is ignored completely. I've filed
#460609 with a patch to fix this.
Interestingly, resolvconf itself internally collapses the
domain
and
search directives into the
search directive of the
/etc/resolv.conf it generates, so I can't quite get the same
/etc/resolv.conf generated as would be generated without resolvconf
being used. No big deal, the behaviour should be the same. The
domain directive is largely unnecessary as I understand it.
I have unearthed what I consider to be a bug with the
domain-search
option handling code in the client. It seems to be largely benign, apart
from causing the client to emit some errors when it's obtaining a lease that
contains the
domain-search option, and possibly not splitting the
domains in the
domain-search option correctly. There's also another
(I think unrelated) warning that gets emitted as well. I'm waiting to hear
back from upstream about both.
I'm not going to package the recently released 4.0 DHCP until I've figured
out a transition plan to go from the old DHCP v2 packages to the v3 ones.