View Full Version : DNS lookup taking too long

October 12th, 2011, 04:15 PM
Hey there,

I don't know if it was just a coincidence of a Ubuntu update and changing my router but after I bought a new one, the DNS lookup takes too much long.
I keep seeing "Sending request..." on my browser for way too long or even on a ping request on the terminal. I've checked on a Windows I have installed on the same notebook and everything is ok.
I've disabled IPv6 and a few other solutions proposed here but nothing seems to work.
I'm running Ubuntu 11.04 x64 on a DELL Vostro 3500 and have never had such a problem.
The router is a ASUS RT-N10+.

Thank you very much.

October 12th, 2011, 05:08 PM
Have you tried putting in the IP address instead of name?

Eg in a terminal window,

oping google.com

You should get an associated IP address for google eg

Put that in your browser.
Any faster or just the same?

October 12th, 2011, 05:10 PM
Much faster.

October 12th, 2011, 05:12 PM
Hows your /etc/resolv.conf looking

Any bogus entries? Anything in there which may be resolving to old unused addresses?

October 12th, 2011, 06:28 PM
I haven't touched it on purpose.
It contains the following:

# Generated by NetworkManager

I don't know if any of these should be considered as bogus or not. The first IP entry belongs to my router. May that be the cause or is it ok?

October 12th, 2011, 07:11 PM
mayhap is a dud?

try opening a terminal

sudo tcpdump -nnvvXS -i any port 53

Go to google or whichever, from that machine

see if it tries

You should see a packet and a response.
If it doesnt maybe thats adding to delay

Becuase it may try that one first , then give up and go to the public one

October 12th, 2011, 07:54 PM
Yes, I think that might be what I'm seeing:

15:51:20.650369 IP (tos 0x0, ttl 64, id 38186, offset 0, flags [DF], proto UDP (17), length 68) > [udp sum ok] 40533+ A? clients1.google.com.br. (40)
0x0000: 4500 0044 952a 4000 4011 222b c0a8 0102 E..D.*@.@."+....
0x0010: c0a8 0101 cb32 0035 0030 6756 9e55 0100 .....2.5.0gV.U..
0x0020: 0001 0000 0000 0000 0863 6c69 656e 7473 .........clients
0x0030: 3106 676f 6f67 6c65 0363 6f6d 0262 7200 1.google.com.br.
0x0040: 0001 0001 ....
15:51:21.646239 IP (tos 0x0, ttl 64, id 38285, offset 0, flags [DF], proto UDP (17), length 59) > [udp sum ok] 11167+ A? google.com.br. (31)
0x0000: 4500 003b 958d 4000 4011 99fb c0a8 0102 E..;..@.@.......
0x0010: c911 806d ddd9 0035 0027 729d 2b9f 0100 ...m...5.'r.+...
0x0020: 0001 0000 0000 0000 0667 6f6f 676c 6503 .........google.
0x0030: 636f 6d02 6272 0000 0100 01 com.br.....
15:51:21.906067 IP (tos 0x0, ttl 252, id 61818, offset 0, flags [DF], proto UDP (17), length 253) > [udp sum ok] 11167 q: A? google.com.br. 5/4/2 google.com.br. A, google.com.br. A, google.com.br. A, google.com.br. A, google.com.br. A ns: google.com.br. NS ns4.google.com., google.com.br. NS ns3.google.com., google.com.br. NS ns2.google.com., google.com.br. NS ns1.google.com. ar: ns1.google.com. A, ns2.google.com. A (225)
0x0000: 4500 00fd f17a 4000 fc11 814b c911 806d E....z@....K...m
0x0010: c0a8 0102 0035 ddd9 00e9 7140 2b9f 8180 .....5....q@+...
0x0020: 0001 0005 0004 0002 0667 6f6f 676c 6503 .........google.
0x0030: 636f 6d02 6272 0000 0100 01c0 0c00 0100 com.br..........
0x0040: 0100 0000 0e00 044a 7dea 50c0 0c00 0100 .......J}.P.....
0x0050: 0100 0000 0e00 044a 7dea 51c0 0c00 0100 .......J}.Q.....
0x0060: 0100 0000 0e00 044a 7dea 52c0 0c00 0100 .......J}.R.....
0x0070: 0100 0000 0e00 044a 7dea 53c0 0c00 0100 .......J}.S.....
0x0080: 0100 0000 0e00 044a 7dea 54c0 0c00 0200 .......J}.T.....
0x0090: 0100 0026 6b00 1003 6e73 3406 676f 6f67 ...&k...ns4.goog
0x00a0: 6c65 0363 6f6d 00c0 0c00 0200 0100 0026 le.com.........&
0x00b0: 6b00 0603 6e73 33c0 7fc0 0c00 0200 0100 k...ns3.........
0x00c0: 0026 6b00 0603 6e73 32c0 7fc0 0c00 0200 .&k...ns2.......
0x00d0: 0100 0026 6b00 0603 6e73 31c0 7fc0 bb00 ...&k...ns1.....
0x00e0: 0100 0100 0523 4900 04d8 ef20 0ac0 a900 .....#I.........
0x00f0: 0100 0100 0523 4b00 04d8 ef22 0a .....#K....".

October 12th, 2011, 08:57 PM

The trace seems to have caught a packet going from > <-- this is the first IP address in resolv.conf

It gets no response, times out and then sends another packet to the second DNS >

It gets a response from this.

You can do one of two things,

Try commenting out the first line in resolv.conf

(put a hash before the address so it doesn't use it.)
This way it will only use 209

Or you can figure out if your router will handle dns resolution and change to that.

Maybe try changing to

or try a different dns server altogether which may be faster
For this, replace both lines with
(public dns)

October 12th, 2011, 09:00 PM
+1 to commenting out the first entry. That being said, if the router is set up right, it would pass on dns requests that aren't in it's local database, without causing them to timeout.

Could try a factory reset of the router to see if that helps.

October 12th, 2011, 09:09 PM
Not sure it will speed things up, but no harm seeing

October 12th, 2011, 10:11 PM
Well, that was exactly the problem. Thank you very very much!

Is there any way to correct that on the router?
Why on Windows everything seems to work fine (maybe because it doesn't check the router for the DNS answer)?
And will there be any problems if I join a different network and then come back to mine again? (I don't know if that settings contianed in the file are set dinamically)

October 12th, 2011, 10:14 PM
You can set static DNS on the router, but where that is located would depend on the router.

October 12th, 2011, 10:19 PM
In windows , opena command prompt,

type ipconfig /all
it should say what DNS you are using in there

It would be interesting to see what address that uses

October 12th, 2011, 10:38 PM
Both Windows and Ubuntu are set to get the DNS dinamically from the DHCP service on the router. The router is also set to get the DNS' from the Internet modem dinamically.

Can't get on Windows right now because I'm running some jobs.

I think this post might be helpful to some other users with the same problem as I've seen around here.

Thank you guys again so much.