Bug 8383

DHCP has two options for returning "search" data for resolveconf.  One is "domain-name" which has been around forever, and returns a single domain name.  The newer one, although 3 or 4 years old at this point, is "domain-search", which returns a list of domains to be searched in order.

According to the dhclient.conf manpage on the net at http://linux.die.net/man/5/dhclient.conf :

 By default, the DHCPv4 client requests the subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-search, domain-name-servers, host-name, nis-domain, nis-servers, ntp-servers and interface-mtu options

However, according to *our* dhclient man page:

By  default,  the  DHCPv4  client
       requests  the  subnet-mask,  broadcast-address,  time-offset,  routers,
       domain-name, domain-name-servers and host-name options while the DHCPv6
       client requests the dhcp6 name-servers and domain-search options.

In actual use, if you set the dhcpd server to return domain-search rather than domain-name, dhclient will either produce no search line at all in resolv.conf, or (occasionally, and don't ask me how it decides this) it will produce a search line with a single token of the unqualified hostname, e. g. "search ftgme2".

dhcpcd, on the other hand, has no problem with domain-search and produces a correct resolv.conf.  But we use dhclient by default.  We also do not provide a dhclient.conf file, which I assume means that we get only the defaults.

This is particularly annoying because NetworkManager uses dhclient by default, and at present overriding to use dhcpcd doesn't work.

So, the question is, why does our dhclient differ in both behavior and man-page from the version given above ?  If it's old, then it needs to be upgraded.

Possibly related is a post from a year ago at http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029209.html from someone claiming to have created a patch that allows dhclient to handle domain-search.