hi everyone,

i have a nb5plus4w modem/router at home which acts as a dhcp server on my lan. upon connection it instructs the clients to use 192.168.1.1 as a dns server (which is the ip address of the router) and linux machines are happy to use that in /etc/resolv.conf.

now the issue is that under these conditions dns resolution is sloooow. there have been some discussions on the net saying that the router is not a 'real' dns server (don't know what that means), but the only way i have been able to get around the issue is to edit /etc/resolv.conf to use my isp's dns servers and then chattr -i the file so that dhcpcd doesn't change it.

this approach works for the desktop and even though it is ugly it's effective. the laptop is a different issue. if i take it out of the house i have to chattr -i and let the new network put it's dns addresses in and then change it all back when i get home....

so, the question is... can i do something to stop doing chattr and get the dns performance of a windows machine (dns resolution is quick on the windows machines)?

You'd probably be better off using two or so free public DNS servers (in /etc/resolv.conf) that the router -- routers tend (not always, but tend) to not update after a while and you lose DNS.

Try a couple of the DNS servers from http://theos.in/windows-xp/free-fast...ns-server-list (there are many other sites that list public DNS servers). Use ping on some of the addresses and find a couple that are electrically close to you (you're looking for the shortest times) then put them in /etc/resolv.conf like so
You want two in case the first goes away; more than two is overkill.

Hope this helps some.

doesn't really solve my problem... when i take the laptop to work i'm behind proxy so external dns servers won't work... i'd really like to use whatever dns the dhcp server on the router tells me to use (the router itself i most cases). i'd like to get to the bottom of why a windows machine can perform fast dns resolution and a linux box cannot (and they both use the router as a dns server).

is it maybe something to do with dns cache?

Is DNS resolving slow when you dig and nslookup, or is it only while you are browsing?

dig is slow... but there is something interesting here...

with my isp's dns servers dig google.com took 17msec.

so then i changed /etc/resov.conf to point to my router (192.168.1.1) and when i ran dig this is what i got

after which it paused for like 3 or 4 seconds and then dig continued to resolve google.com in 1msec.

strange...

Some people probably don't think that a caching only DNS server is really a DNS server...but then some people don't know what they are talking about and, from what you have said, caching is all you need.

That said, there is not much memory in an appliance box, such as a router, and it is probably the case that it cannot keep many entries in its cache: in normal usage this is probably not a big problem, but you can almost certainly come with use cases in which a bigger cache is an advantage.


...a bit brutal, but if it works, it works... some ISP's DNS servers are either a bit slow or a bit erratic in performance, but if yours are OK, that's fine.

There are applications particularly for benchmarking DNS. I like this one (DNS Benchmark), but its a windows program that runs under wine. Alternatively, you could try this (namebench).

That is odd; I don't know why that would happen, unless you have done something particularly odd to cause it. Why a query on port 53 does not cause a response on port 53 is intriguing.

Windows, as I understand it, caches DNS on the box -- which is OK until there is some kind of problem (it caches both valid and invalid entries). Thus, after a few tries, Windows is "quicker." If you really care about what Windows is doing, take a look at http://www.updatexp.com/dns-windows-xp.html and see what you think.

Don't know about your router but I suspect that you can enter DNS server addresses in its setup (you can with a Cisco/Linksys) and that should be just about as fast as his little feet will run. The router may or may not cache from those entries (as far as I can tell Linksys does not); hopefully it does not unless it updates its DNS cache every few hours.

If you do this, you don't need any entries in /etc/resolv.conf save the initial
That entry is made during system installation from /etc/HOSTNAME for you.

You might want to ping the DNS address your ISP gave you and compare that against, say, the Google DNS servers (8.8.8.8 and 8.8.4.4); put the shortest response time first, followed by one or two others.

I use fixed-IP addressing for all my systems so I really have no idea how DHCP would be affected by having DNS entries in the router's setup but I suspect that the performance might be similar to what I experience with copper wire ADSL; i.e., quick. When I am off in the boonies using either dial-up or a Verizon wi-fi thingie KPPP automagically adds a temporary DNS entry (or two) to /etc/resolv.con (I have to use loopback for dial-up or wi-fi but the same thing happens at public library that requires DHCP -- a temporary DNS entry in /etc/resolv.conf).

I dunno, give it a shot and see what happens.

Hope this helps some.

If you don't have a domain name to serve authoritatively, then caching is all you need to do for DNS.

I had a similar experience with a Linksys router, and I didn't want to change my network settings to use a fixed /etc/resolv.conf, so what I did was to configure the router to give me a different DNS server. In the control panel, I told it to give me Google's DNS cache. For Linksys, this is in "Setup > Basic Setup > Static DNS Server 1/2/3". Maybe your router has a similar option. Now when dhcpcd writes the contents of /etc/resolv.conf, I get this:

According to that URL

It is perfectly legitimate to cache DNS look-ups, if you do it right, but this isn't doing it right.

IIRC, every DNS entry has a 'time to live'. Any step along the chain can keep it until the time to live runs out and then must discard it (obviously, preserving the TTL value, if it is passed on to a requester further down the chain). This is particularly useful if you are managing servers and need to shift things around; you can set a TTL that lets things hold on to the old server address until the server swap occurs, and you can even get something like PDNS to do the time calculations for you.

For an endpoint to decide that some particular time, rather than the specified TTL, is the time to keep stuff in the cache is a bit risky and against the requirements of the relevant RFC.

If you want to do this correctly, you run a caching DNS server locally*. AFAIK all of the popular candidates (Dnsmasq, maradns, powerdns, djbdns and even BIND) do respect the TTL values....and do what windows does, but do it properly. OK, you do have to run a separate program, but, with the possible exception of BIND, it is not hard.

* to run it locally is on your side of the bottleneck (the high latency part of the network). It might be on your router, if you run a replacement router firmware (DD-WRT, tomato, etc) it could be on a server on your network, it could be on your workstation - the most appropriate will depend on your usage pattern and network. But, as I say, your existing router is probably running a small DNS cache, and if it goes to a reasonably quick upstream server (which need not be your ISP, but that is probably your default) then you'll probably not see a big improvement. OTOH, if your upstream server is v. slow, and some are, there might be a reasonable win from this.

i would have solved my problem ages ago if i actually read what is on my laptop screen and just stared at it like a tool.

wicd allows for static dns to be specified for a particular connection! so i have undone all the stupid chattr +i /etc/resolv.conf crap and specified my isp's dns servers in wicd for my home wireless and eth0 (as my home lan is the only lan causing the problem) and it's all good.

thanks for your help everyone!