The "domainname" init script puts a "domain" option line at the end of
resolv.conf, in spite of the "search" keyword being present in that file.
Until (at least) baselayout-1.10.4 the "domain" line used to go to the
beginning of the file.
The new version makes it impossible to use the "search" option, since
the last instance of any "domain" and "search" options is taken. See
(Also, I cannot find any ChangeLog entry about this change.)
it's in the ChangeLog, read harder
if you dont like the domainname script overriding local 'search' options, remove it from your boot (`rc-update del domainname`)
Found the ChangeLog entry (sorry about that) and also bug 48277. Removing
domainname from boot is not an option since it is needed to set the
I still do not see what is the point in adding the domain option at the end
of the file since the awk script in domainname removes all lines starting
with "domain". So putting it at the end just breaks the search option:
| The domain and search keywords are mutually exclusive. If
| more than one instance of these keywords is present, the
| last instance wins.
Maybe I should add that /usr/bin/host still works if "search" is before "domain",
but /bin/ping and /usr/bin/ssh will fail ("unknown host").
then just run `rm /etc/dnsdomainname`
as for ssh/ping vs host ... the bind-tools implement their own resolver library while ssh/ping use the glibc one
If you really want the "domain" option to take precedence then you should
be consequent and strip all "search" options from the file. To leave these
unused lines in resolv.conf is only confusing.
just talked with azarah and he pointed how our 3 config files in /etc/ (hostname / dnsdomainname / nisdomainname) are completely Gentoo specific
i'll look at updating the scripts to use conf.d files and in the meantime add a config option to domainname to be a little more user friendly ... not everyone realizes how resolv.conf / domainname works and how using the domainname script is wrong if you want to manage your own resolv.conf
*** Bug 97323 has been marked as a duplicate of this bug. ***