On 27/07/2014 12:30, Grand Duet wrote:
2014-07-27 13:39 GMT+03:00 Walter Dnes <[email protected]>:
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
