1 |
2014-07-27 21:14 GMT+03:00 Kerin Millar <kerframil@×××××××××××.uk>: |
2 |
> On 27/07/2014 12:30, Grand Duet wrote: |
3 |
>> |
4 |
>> 2014-07-27 13:39 GMT+03:00 Walter Dnes <waltdnes@××××××××.org>: |
5 |
>>> |
6 |
>>> On Sun, Jul 27, 2014 at 12:21:23PM +0300, Grand Duet wrote |
7 |
>>>> |
8 |
>>>> This is a continuation of the thread: |
9 |
>>>> "Something went wrong with DNS, plz help!" |
10 |
>>>> |
11 |
>>>> Now, the issue became clearer, so I decided to start |
12 |
>>>> a new thread with more descriptive Subject. |
13 |
>>>> |
14 |
>>>> In short: the contents of the file /etc/resolv.conf |
15 |
>>>> is unpredictably different from one reboot to another. |
16 |
>>>> It is either |
17 |
>>>> # Generated by net-scripts for interface lo |
18 |
>>>> domain mynetwork |
19 |
>>>> or |
20 |
>>>> # Generated by net-scripts for interface "eth0" |
21 |
>>>> nameserver My.First.DNS-Server.IP |
22 |
>>>> nameserver My.Second.DNS-Server.IP |
23 |
>>>> nameserver 8.8.8.8 |
24 |
>>>> |
25 |
>>>> I tried to chmod this file to be unwrittable even for root |
26 |
>>>> but after a reboot it have been overwritten anyway. |
27 |
>>>> |
28 |
>>> A similar problem was noted at... |
29 |
>>> https://forums.gentoo.org/viewtopic-t-816332-start-0.html |
30 |
>> |
31 |
>> |
32 |
>> Like in the thread above, I also have a line |
33 |
>> dns_domain_lo="mynetwork" |
34 |
>> in my /etc/conf.d/net file. It says nothing to me |
35 |
>> and I do not remember how it got there. |
36 |
>> |
37 |
>> But somewhere on Gentoo forum I have found the following |
38 |
>> explanation: "If you only specify dns_domain_lo="foo" and |
39 |
>> restart the lo interface it will put "domain foo" in /etc/resolv.conf |
40 |
>> and remove everything else." |
41 |
> |
42 |
> |
43 |
> You can specify dns_domain - without an interface suffix - which ought to |
44 |
> prevent this behaviour. However, you'd be better off getting rid of it |
45 |
> altogether. |
46 |
|
47 |
It is my first reboot after commenting out the line |
48 |
dns_domain_lo="mynetwork" |
49 |
and so far it went good. |
50 |
|
51 |
Moreover, the file /etc/resolv.conf has not been overwritten. |
52 |
|
53 |
I still have to check if everything else works fine and |
54 |
if I will get the same result on the next reboot |
55 |
but I hope that the problem has been solved. |
56 |
|
57 |
> All the option does is define the suffix(es) that are appended |
58 |
> by the resolver under certain conditions. These conditions are as follows: |
59 |
> |
60 |
> a) the initial name isn't qualified (contains no dots) [1] |
61 |
> b) the initial name could not be resolved (NXDOMAIN response) |
62 |
> |
63 |
> Making up fake domains for this setting, as many Gentoo users are induced |
64 |
> into doing, serves no purpose. Let's assume that I have "fakedomain" as a |
65 |
> search domain in resolv.conf. |
66 |
> |
67 |
> Let's see what happens for a short name: |
68 |
> |
69 |
> $ host -t A -v shorthost | grep -e Trying -e NX |
70 |
> Trying "shorthost.fakedomain" |
71 |
> Trying "shorthost" |
72 |
> Host shorthost not found: 3(NXDOMAIN) |
73 |
> |
74 |
> Result: two spurious DNS lookups, each resulting in NXDOMAIN. You may use |
75 |
> tcpdump to confirm that there are indeed two. |
76 |
> |
77 |
> Now, let's try looking up a fully qualified hostname that happens not to |
78 |
> exist: |
79 |
> |
80 |
> $ host -t A -v nonexistent.google.com | grep -e Trying -e NX |
81 |
> Trying "nonexistent.google.com" |
82 |
> Trying "nonexistent.google.com.fakedomain" |
83 |
> Host nonexistent.google.com not found: 3(NXDOMAIN) |
84 |
> |
85 |
> Result: The first lookup fails and is immediately followed by an another |
86 |
> lookup that is completely and utterly useless. Had a search domain _not_ |
87 |
> been defined, then the resolver could have concluded its efforts after the |
88 |
> first NXDOMAIN response. |
89 |
> |
90 |
> The bottom line is that it only makes sense to define search domain(s) if |
91 |
> the following two conditions hold true. |
92 |
> |
93 |
> 1) You want to be able to resolve hostnames in their short form |
94 |
> 2) Records for said names will exist in a known, *valid* domain |
95 |
> |
96 |
> Otherwise, don't bother and leave it to the DHCP server to decide [2]. While |
97 |
> I haven't looked at the handbook lately, it has had a history of prescribing |
98 |
> dns/domain related options without adequate explanation and, in some cases, |
99 |
> with outright misleading information [3]. |
100 |
> |
101 |
> On a related note, some people prefer to manage resolv.conf themselves and |
102 |
> it is not initially obvious as to how to do this while also using DHCP. |
103 |
> Trying to make the file immutable is not a proper approach. The trick is as |
104 |
> follows: |
105 |
> |
106 |
> * Specify dhcpd_eth0="nodns" (do this for any dhcp-using interfaces) |
107 |
> * Do not specify any dns or nameserver related settings in conf.d/net |
108 |
> |
109 |
> The netifrc scripts will then leave resolv.conf alone. |
110 |
|
111 |
Thank you for the nice explanation that convinced me that I do |
112 |
not need that feature at all. |
113 |
|
114 |
I do not use DHCP at all but I got the general point. |
115 |
|
116 |
> [1] Check out the ndots option in the resolv.conf(5) manpage |
117 |
> [2] DHCP servers may specify a search domain for clients with option 15 |
118 |
> [3] https://bugs.gentoo.org/show_bug.cgi?id=341349 |