LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   nameserver entries in /etc/resolv.conf (https://www.linuxquestions.org/questions/linux-software-2/nameserver-entries-in-etc-resolv-conf-829691/)

Ron7 09-01-2010 04:49 AM

nameserver entries in /etc/resolv.conf
 
As I understand it, /etc/resolv.conf is rewritten at boot time by NetworkManager (a script?). I have a problem in the order the nameserver entries are written by my system (F13). This is:

Code:

nameserver 192.168.1.1
nameserver xxx.233.0.4
nameserver xxx.233.0.3

The 192 address is my modem/firewall/DNS. The others are my ISP nameservers. The result is Firefox has to timeout the 192 address before it tries one that will actually resolve a name, making firefox slow.

My 'cure' is to manually edit the file after every reboot. Where does NetworkManager get the nameserver IPs? How can I change the order? I might even get away with dropping the 192 address as my hosts file has all my local hosts enumerated.

xeleema 09-01-2010 05:03 AM

Greetingz!

That file is created when your system picks-up it's DHCP settings. You can check the configuration for your DHCP client service (look in /etc) and see if you can disable it from overwriting your /etc/resolv.conf file.

Or you could throw this in your rc.local script

Code:

cat /dev/null > /etc/resolv.conf && \
printf "nameserver 192.168.1.1\nnameserver xxx.233.0.4\nnameserver xxx.233.0.3\n" >> /etc/resolv.conf


Ron7 09-01-2010 09:56 PM

It appears that the unwanted 192.168.1.1 nameserver entry being set as the first entry in /ect/resolv.conf is because that is set as the "default gateway". The pri/sec nameservers are read from ifcfg-eth0, I presume. (/sbin/route output below)

Code:

Kernel IP routing table
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
192.168.1.0    *              255.255.255.0  U    1      0        0 eth0
default        192.168.1.1    0.0.0.0        UG    0      0        0 eth0

Raises an interesting question about setups for a typical home network with a DSL modem/DNS/firewall. All network devices get their IP from the modem/DNS via DHCP and NIC lookup (for security, only NICs I specifically authorize get an IP, wired, or wireless).

The DNS also has the short-form name for each device, though linux and win32 boxes have their canonical name configured locally as well. In addition, all linux/win32 machines have an up to date hosts file, but some devices (media servers, wireless IR devices etc) rely on NIC to IP lookup in the modem.

I guess Firefox under linux uses the nameservers from resolv.conf in order, hence the delay as it queries the modem before trying my ISP's nameservers. So...
1. Should the default gateway in the kernel routing table be set to one of the ISP nameservers?
2. Does having the modem address (192.168.1.1) serve any purpose at all in the routing table on a linux box with a complete, up-to-date /etc/hosts file? (nsswitch.conf is set "hosts file dns")
3. Is the modem (a Netcom NB6Plus4W) keeping any routing tables that would justify including it as a nameserver and why does it take so long to decide it can't resolve a name?
I've tried editing out the 192.168.1.1 entry from resolv.conf and this speeds up Firefox and does not *seem* to cause any other problems, but as it stands, the file will be rebuilt with the 192...1 address on reboot.

I'd have thought that having the modem/DNS first would be ok as it would quickly say "not known", but cache the resolved name when the ISP nameserver(s) resolves it. Next time the modem could resolve the name quickly without going "outside". Obviously not.

I guess my general configuration must be typical of 1000's of home systems, so this must have been discussed before, but I can't find the search terms that give answers.

exvor 09-01-2010 10:30 PM

AH HAH another person with this scourge of an issue as well. Indeed I have battled the great dhcpcd /etc/reslov.conf file problem before and I have some sobering news as well as possible solutions. First ones first. According to the dhcpcd mailing list and its creators you should be able to add reslov.conf to the nohook section of your dhcpcd.conf file section to prevent it from trying to write this file every time.

However on practice it just makes an empty file and overwrites anyway anything you put there. (this is extremely frustrating as it did not do this before) but its something you can try first if your distro is not using the most current version of dhcpcd like I am. Another thing you can do and is what I do is edit the file and then set the sticky bit to prevent overwrite even by the root user. As root just issue a chmod +s /etc/reslov.conf and that should prevent overwrite.

P.S. I have expressed this problem on the mailing list but it kinda falls on def ears as they insist that if you put the nohook in that it prevents writing to that file. maybe one day they will just stop adding local stuff to the reslov file.
Happy hunting

Ron7 09-02-2010 12:07 AM

Quote:

AH HAH another person with this scourge of an issue as well.
*sigh* I'll probably go the brute force chmod +s route. What distro are you using? I'm on Fedora 13 and there's no dccpcd.conf in /etc, nor can I find a man page for dhcpcd or dhcpcd.conf (tried sections 5 and 8 for good luck).

xeleema 09-02-2010 12:30 AM

1 Attachment(s)
@Ron7

Did you not try this?
Quote:

Throw this in your rc.local script
Code:

cat /dev/null > /etc/resolv.conf && \
printf "nameserver 192.168.1.1\nnameserver xxx.233.0.4\nnameserver xxx.233.0.3\n" >> /etc/resolv.conf


If you're command-line-shy (which is totally okay), then try this;

From your Windows Manager (aka "Desktop", and I'm assuming Gnome);
1) Click Applications -> System Settings -> Network.
2) Double-click the Ethernet device entry in the Devices tab and confirm that:

... "Automatically obtain IP address settings with:" is set to "dhcp".
... "Automatically obtain DNS information from provider" is NOT checked.

3) Add your DNS entries manually for that Ethernet device (see attachment)

exvor 09-02-2010 03:08 AM

Ohh I am not using any distro im on a lfs build. As for not having /etc/dhcpcd.conf I would only assume that fedora does not use it. That or they changed where the configuration file is located.

salasi 09-02-2010 11:13 AM

Quote:

Originally Posted by Ron7 (Post 4085552)
I'd have thought that having the modem/DNS first would be ok as it would quickly say "not known", but cache the resolved name when the ISP nameserver(s) resolves it. Next time the modem could resolve the name quickly without going "outside". Obviously not.

In the case of most domestic modem/routers, the m/r does cache a small number of DNS lookups (this is different from a 'routing table'; don't confuse the two).

This cached value will not last for long (it has a defined 'time to live', which is generally under six hours) and the cache is pretty small in size....and the cache will definitely be empty if you power the device on and off. So, the first time that you access the device (whether after a power cycle or a dormant period) the value that you want will not be in the cache.

In this case, the m/r will try to get a value from its upstream servers, and the delay will be dependant on how quickly they respond (or the time that it takes to time out its accesses to the upstream servers).

What does 'dig' tell you about the resolutions? Is there any sign that resolutions after the first are quicker?

Ron7 09-02-2010 09:28 PM

Quote:

xeleema said:
Did you not try this?
<snip>
vi has been hardwired in my fingers since about 1982 :) so I do everything via the command line unless I can't help it, and yes I edited /etc/resolv.conf to what I wanted, but it gets rewritten on reboot in f9! The chmod +s trick would fix this, but I prefer to understand why and fix the cause rather than the symptom (more fool me).

Ron7 09-02-2010 10:20 PM

Quote:

Originally Posted by salasi (Post 4086111)
In the case of most domestic modem/routers, the m/r does cache a small number of DNS lookups
*snip*
What does 'dig' tell you about the resolutions? Is there any sign that resolutions after the first are quicker?

A very interesting experiment. In summary, the M/R does cache, so having it first should be beneficial. The following times are not of much meaning in absolute terms, but their relative value is instructive:

1. Lookup not in any cache (M/R, ISP nameserver): 260mS
2. Lookup cached at ISP, M/R not present, or not first: 40mS
3. Lookup cached in M/R which is first nameserver in resolv.conf: 2mS

So having your modem/router first in /etc/resolv.conf should be the way to go, but I see something very different when querying URLs using Firefox. I got the above numbers from ssh-ing into my home system from uni and recording the Query time reported by dig. I'll get stopwatch times from Firefox over the weekend when I have GUI access to the box.

salasi 09-03-2010 03:45 AM

Quote:

Originally Posted by Ron7 (Post 4086631)
In summary, the M/R does cache, so having it first should be beneficial.

It sounds as if your ISPs nameservers may be slow, at least for uncached entries (and, remember, your first look-up will always be as slow as the upstream source, whether or not you have caching).

You don't have to use your IPS's nameservers. OpenDNS and Google both do a reasonable job with their publicly available nameservers, but if you really want fastest where you are, do some testing. I like DNSBench (works under wine) but, if memory serves, namebench is an alternative.

An alternative would be to use a caching DNS server, locally. There probably isn't a big advantage over using the m/r if that is configured to use something fairly fast as an upstream, but it is an alternative. But, if you do go down this route, BIND isn't usually the best answer.

xeleema 09-03-2010 03:18 PM

Quote:

Originally Posted by Ron7 (Post 4086597)
vi has been hardwired in my fingers since about 1982 :) so I do everything via the command line unless I can't help it, and yes I edited /etc/resolv.conf to what I wanted, but it gets rewritten on reboot in f9! The chmod +s trick would fix this, but I prefer to understand why and fix the cause rather than the symptom (more fool me).

@Ron7
I was asking if you threw those commands into rc.local. That way they would overwrite your /etc/resolv.conf on boot.

If you really wanted to, you could even put it in a cron tab (however, it would have to be on all one line);
Code:

5 * * * * cat /dev/null > /etc/resolv.conf && printf "nameserver 192.168.1.1\nnameserver xxx.233.0.4\nnameserver xxx.233.0.3\n" >> /etc/resolv.conf


All times are GMT -5. The time now is 04:52 AM.