I'm having a problem with DNS resolution in 13.1.

This problem cropped up while I was running current approximately about the time I upgraded to KDE 4.3.5.

Essentially, when I connect to the internet, no command line application is able to resolve any domain names.

Amongst KDE apps, only http:// domain names are resolved (https, ftp, pop, etc all fail).

In Firefox, everything works.

Eventually I figured out that by manually inserting "nameserver 8.8.8.8" (or any DNS server) into /etc/resolv.conf after establishing a connection, my problem is solved. If I always want to use the same DNS server, I could set DHCP_KEEPRESOLV[4]="yes" in rc.inet1.conf, but this isn't really what I want.

I'd just like to know if something changed during the past month or two that has caused me to have to manually set resolv.conf or if there's anything that I can do to fix the problem.

Thanks!

(note that my previous thread http://www.linuxquestions.org/questi...-https-806455/ was about this problem but is incorrectly titled)

Hope if you mentioned the nameserver at your /etc/resolv.conf considerably its too fast to resolve the domain name when you access the internet or local systems by hostname, otherwise the system will search possible DNS server.

In default there may be entry as like this

Kirukan, thanks for the answer.

I forgot to add a critical piece of information. Before I added the nameserver myself, resolv.conf was empty.

I am not aware of any changes to Slackware in the last month or so but I don't use current or DHCP; I do not recall a similar question here on LQ though.

The symptoms of "Amongst KDE apps, only http:// domain names are resolved (https, ftp, pop, etc all fail). In Firefox, everything works" are very strange. AFAIK name resolution has nothing to do with the protocol -- http, https, ftp, pop etc. Perhaps Firefox has a default way of resolving domain names so it works when there are no name servers in resolv.conf.

It might be illuminating to monitor the network for DNS traffic. A suitable command is tcpdump -nnl -i eth0 -s 1536 dst port 53

The key issue is why your resolv.conf is no longer being populated by DHCP (presuming it used to be). Has anything changed on the DHCP server?

The fastest nameservers should™ be your ISP's because they are closest in network terms. The most automated scenario is that their IP addresses are provided by the ISP on connection and, if your computer does not connect directly, your computer gets the DNS server IP addresses from the intervening device.

This ideal scenario goes wrong a) if your ISP does not operate their DNS service well or b) if the DNS server IP addresses are not propagated. a) is rare and can be worked around by configuring public DNS servers. These vary a lot in response times. OpenDNS seem unusually quick; perhaps they co-locate their servers on ISPs' premises; but they do deliver advertising if a name is unresolvable. Level 3 DNS servers are also quick. I don't know about google's. b) can be worked around by manual configuration as you have said you do not want to do.

A workaround for both problems is to use something like dnsmasq. dnsmasq can be configured to use many DNS servers, more than the maximum effective number of 3 that are used from resolv.conf, and it automatically uses the fastest.

If you do decide to go with the workaround of manually populating resolv.conf, I could post a simplistic script that measures DNS server response times to enable you to choose the fastest.

Are you running dhcpcd? Did you uncomment any of the DHCP_KEEPRESOLV lines in /etc/rc.d/rc.inet1.conf?

When resolv.conf is empty, glibc (libnss_dns.so) should query localhost. If you have a DNS server running and listening to connections on localhost, then in most cases there should be no problem.

1 members found this post helpful.

Thanks guanx, that's illuminating

How "normal" is it to have a DNS service listening on 127.0.0.1? Mening "Is it part of a typical default installation?" and if so, have we not shifted the issue from resolv.conf to some other configuration file that the DNS service listening on 127.0.0.1 uses to find its upstream DNS servers?

I forgot what the default option was. In the last step of installation you are prompted to choose which services to activate. If bind is selected, then you have a DNS server at 127.0.0.1. A few moments after startup, bind will cache enough data to resolve host names for you.

"man resolv.conf" says "On a normally configured system this file should not be necessary. The only name server to be queried will be on the local machine".

Thanks guanx

I looked (netsearched and man pages) but did not find how BIND (named) could find DNS servers to use. Given that many are private I cannot imagine a method of finding them automatically. Given only a fledgling understanding I still think BIND needs some manually configured DNS server IP addresses ... ?

The root servers used to be listed in root.hints but now you'll find it at

/var/named/caching-example/named.root

/etc/named.conf may also be configured with "forwarders" which will direct queries the specified server.

1 members found this post helpful.

Thanks for the replies. I need some time to digest everything and try out your suggestions.

For the time being, just so you know I connect using Wicd and have tried both dhcpd and dhclient with the same results. Also, I have been unable to replicate getting an empty resolv.conf. I said it was empty before, but now it appears to contain:
To this, I must add another nameserver (for example OpenDNS or Google's) to avoid the problems in my initial post.

Thanks mRgOBLIN

Maybe this is threadjacking but, on the assumption that something like this mechanism was allowing the OP to do some name resolution with no DNS servers in resolv.conf ...

Does that mean that, in the absence of any manual configuration, the local BIND would be using the root nameservers for all queries? Or do the root nameservers hand out a list of authoritative nameservers for the whole name space? Neither of these options is attractive. In the first case, is it not bad netiquette to access the root nameservers directly? In the second case that would be a huge data transfer and most of the data transferred would not be used -- a very inefficient scenario.

Only if 192.168.1.1 (your LAN/Internet router?) is not an effective DNS resolver. In the ideal case it is automatically configured with your ISP's nameservers and caches lookups thus giving you LAN speed resolution for commonly used names and ISP speed (faster than Internet speed) lookups for many of the rest ("many" meaning the ones that the ISP's nameserver(s) has/have cached).

Assuming the local caching server was active...

If it hadn't already cached a lookup for one of the TLD's it would query the root server to find out who is authoritative for that domain.

The root server tells it who to ask for the next level and it will query that server etc.

It works it's way from the top down until it gets an answer and returns it to the client. Of course it caches much of this info.

So the work is spread among many servers and not all queries would be made to the root servers.

1 members found this post helpful.

Hi,
It makes sense that the router is somehow the problem ... but Firefox always works!