Re: [gentoo-user] resolv.conf is different after every reboot

[Kerin Millar]

On 27/07/2014 12:30, Grand Duet wrote:
> 2014-07-27 13:39 GMT+03:00 Walter Dnes <waltdnes@××××××××.org>:
>> On Sun, Jul 27, 2014 at 12:21:23PM +0300, Grand Duet wrote
>>> This is a continuation of the thread:
>>> "Something went wrong with DNS, plz help!"
>>>
>>> Now, the issue became clearer, so I decided to start
>>> a new thread with more descriptive Subject.
>>>
>>> In short: the contents of the file /etc/resolv.conf
>>> is unpredictably different from one reboot to another.
>>> It is either
>>>    # Generated by net-scripts for interface lo
>>>    domain mynetwork
>>> or
>>>    # Generated by net-scripts for interface "eth0"
>>>    nameserver My.First.DNS-Server.IP
>>>    nameserver My.Second.DNS-Server.IP
>>>    nameserver 8.8.8.8
>>>
>>> I tried to chmod this file to be unwrittable even for root
>>> but after a reboot it have been overwritten anyway.
>>>
>> A similar problem was noted at...
>> https://forums.gentoo.org/viewtopic-t-816332-start-0.html
>
> Like in the thread above, I also have a line
>      dns_domain_lo="mynetwork"
> in my /etc/conf.d/net file. It says nothing to me
> and I do not remember how it got there.
>
> But somewhere on Gentoo forum I have found the following
> explanation: "If you only specify dns_domain_lo="foo" and
> restart the lo interface it will put "domain foo" in /etc/resolv.conf
> and remove everything else."

You can specify dns_domain - without an interface suffix - which ought 
to prevent this behaviour. However, you'd be better off getting rid of 
it altogether. All the option does is define the suffix(es) that are 
appended by the resolver under certain conditions. These conditions are 
as follows:

   a) the initial name isn't qualified (contains no dots) [1]
   b) the initial name could not be resolved (NXDOMAIN response)

Making up fake domains for this setting, as many Gentoo users are 
induced into doing, serves no purpose. Let's assume that I have 
"fakedomain" as a search domain in resolv.conf.

Let's see what happens for a short name:

   $ host -t A -v shorthost | grep -e Trying -e NX
   Trying "shorthost.fakedomain"
   Trying "shorthost"
   Host shorthost not found: 3(NXDOMAIN)

Result: two spurious DNS lookups, each resulting in NXDOMAIN. You may 
use tcpdump to confirm that there are indeed two.

Now, let's try looking up a fully qualified hostname that happens not to 
exist:

   $ host -t A -v nonexistent.google.com | grep -e Trying -e NX
   Trying "nonexistent.google.com"
   Trying "nonexistent.google.com.fakedomain"
   Host nonexistent.google.com not found: 3(NXDOMAIN)

Result: The first lookup fails and is immediately followed by an another 
lookup that is completely and utterly useless. Had a search domain _not_ 
been defined, then the resolver could have concluded its efforts after 
the first NXDOMAIN response.

The bottom line is that it only makes sense to define search domain(s) 
if the following two conditions hold true.

   1) You want to be able to resolve hostnames in their short form
   2) Records for said names will exist in a known, *valid* domain

Otherwise, don't bother and leave it to the DHCP server to decide [2]. 
While I haven't looked at the handbook lately, it has had a history of 
prescribing dns/domain related options without adequate explanation and, 
in some cases, with outright misleading information [3].

On a related note, some people prefer to manage resolv.conf themselves 
and it is not initially obvious as to how to do this while also using 
DHCP. Trying to make the file immutable is not a proper approach. The 
trick is as follows:

   * Specify dhcpd_eth0="nodns" (do this for any dhcp-using interfaces)
   * Do not specify any dns or nameserver related settings in conf.d/net

The netifrc scripts will then leave resolv.conf alone.

--Kerin

[1] Check out the ndots option in the resolv.conf(5) manpage
[2] DHCP servers may specify a search domain for clients with option 15
[3] https://bugs.gentoo.org/show_bug.cgi?id=341349