From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id CB82213877A for ; Sun, 27 Jul 2014 18:14:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4A151E0A64; Sun, 27 Jul 2014 18:14:40 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 365B1E09E6 for ; Sun, 27 Jul 2014 18:14:39 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway1.nyi.internal (Postfix) with ESMTP id B1CC9209BD for ; Sun, 27 Jul 2014 14:14:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 27 Jul 2014 14:14:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.co.uk; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=pPjDcJ4BNAUq9KPWKMNr+TGsKAI=; b=E8Mr2QcVQZfwC3MGtYT02ac6nWMC 9R27MlVEetVBdg25wASbp/5dO7MzfrNVVUvgSI0qdN79X4uRsUYvi0smSzW1J6b+ 90FVgvq4662VDF3J08vHnhkV2vwqvMyLAWc731htGmePLy2AIV3MGjeISOcIIhw2 Ii+4tg/UgG2xi7U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=pPjDcJ4BNAUq9KPWKMNr+T GsKAI=; b=IyfnguKiYRoAoRv88/dS7v57faOlnJzzKhnBJikmXwMIOvJ0bzqY41 SCKWU6v+L3c5Bf6UkjxvVvO8LW07SNyQXFCPrT5Srsv1EgRP9JVF5H11Xvb16C3r JsXg/VK+pZH+HafVchYUurPhp/2DSfZSia7l57UDzF8sRl1+C7rCI= X-Sasl-enc: jGBC9lewEpMA4kC9OyNRjBIlOLI9TTo9jNy4hhPpi0nd 1406484875 Received: from [192.168.1.146] (unknown [77.101.146.254]) by mail.messagingengine.com (Postfix) with ESMTPA id B63836801C3 for ; Sun, 27 Jul 2014 14:14:35 -0400 (EDT) Message-ID: <53D54189.603@fastmail.co.uk> Date: Sun, 27 Jul 2014 19:14:33 +0100 From: Kerin Millar User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20140623 FossaMail/24.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] resolv.conf is different after every reboot References: <20140727103904.GA5579@waltdnes.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 0cdabfec-ecc8-4d8e-bcd7-7b65ae9ba56e X-Archives-Hash: f6ba22716620b27901c4bce4783c03d6 On 27/07/2014 12:30, Grand Duet wrote: > 2014-07-27 13:39 GMT+03:00 Walter Dnes : >> 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