LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 09-29-2006, 10:30 AM   #1
Avatar
Member
 
Registered: May 2001
Location: Canada
Distribution: old ones
Posts: 532

Rep: Reputation: 30
Unhappy Help with my linux DNS server - lookups slow


Hi Linux users,

I hava a Linux server in a business environment. All the PCs connected to it are running Windows XP (and one with Win 2K). The server itself is an IBM eServer xSeries 335 with Linux Mandrake MultiNetwork Firewall, kernel 2.4.18 - I know its old but all attempts to upgrade have failed (another story).

The server has 2 network cards eth0 and eth1. I use this server as a gateway, firewall, proxy, and DNS server between all the PCs in the company and the DSL Internet connection.

My proxy software is squid. I was looking in the squid logs because the Internet has been really slow lately and I've gotten complaints about it. Anyway, the squid log shows everything working well except the DNS lookups.

Under the heading: median service time (seconds) I have: 5 min: 10.14244; 60 min: 9.70242. This tells me that clients are waiting up to 10 seconds for a page to be displayed while the DNS lookup is going on.

I am using a standard ADSL connection with dynamic IP address and named for the DNS server software. I don't really know much about DNS or how it's setup on my server. I have restarted the named service a number of times and it didn't help.

I have noticed that if I manually enter a DNS server in Windows XP (don't use the DHCP assigned one, aka my Linux box) then the Internet seems faster.

Any suggestions on what to do or how to enter an alternative DNS server on my Linux box?

TIA
 
Old 09-30-2006, 09:24 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,414

Rep: Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967
well all your dns servers just live in /etc/resolv.conf, find a better one and off you go, but at the same time you might like to use a tool like wireshark or tcpdump to capture what is happening here, and see what actually happens on a typical dns lookup, you may see errors coming back from certain servers etc...
 
Old 10-18-2006, 10:43 AM   #3
Avatar
Member
 
Registered: May 2001
Location: Canada
Distribution: old ones
Posts: 532

Original Poster
Rep: Reputation: 30
Thanks, you're right, I forgot about /etc/resolv.conf: I thought it was for the local machine and not the DNS/DHCP server's clients too. Well I can see the one server in there is not responding well, how does one go about "finding a better one". Is it possible to just use 127.0.0.1? I have the named service running. Thanks.
 
Old 10-18-2006, 12:36 PM   #4
RHAPOLLO
LQ Newbie
 
Registered: Oct 2006
Location: TX, US
Distribution: Fedora12
Posts: 13

Rep: Reputation: 0
DNS lookup

Hi,

127.0.0.1 is the loopback (lo) interface for ICMP packets. I don't recommend using it as a a DNS address in /etc/resolv.conf. However, you may wanna try configuring your Network using static IP's on the private ethernet interface (route to your local LAN). The suggestion about tcpdump is absolutely right, I strongly agree to do that first. Also, try to turn off the DNS lookup in the /etc/httpd/conf/httpd.conf and see if this will make the web access faster, .. I hope ...

Please keep me updated ..

A.T., RHCE

Thanks
 
Old 10-19-2006, 11:56 AM   #5
Avatar
Member
 
Registered: May 2001
Location: Canada
Distribution: old ones
Posts: 532

Original Poster
Rep: Reputation: 30
Unhappy

Hello,

I do use a static IP on my local ethernet interface. The other interface is connected to an ADSL modem.

I have tried TCPDUMP but I have no idea how to read the results. Here is what a capture looks like:

Code:
tcpdump: listening on ppp0
11:49:51.597918 60.11.125.55.53355 > 64.231.80.147.1027:  udp 458 (DF)
11:49:53.798904 64.231.80.147.1062 > 216.94.106.2.domain:  19480+ A? smtp10.on.aibn.com. (36)
11:49:54.387035 216.94.106.2.domain > 64.231.80.147.1062:  19480 8/4/4 A 67.69.240.40, A 67.69.240.41 (325) (DF)
11:49:54.388210 64.231.80.147.1510 > 67.69.240.40.smtp: S 1730788249:1730788249(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
11:49:54.398263 67.69.240.40.smtp > 64.231.80.147.1510: S 807243513:807243513(0) ack 1730788250 win 16384 <mss 1412> (DF)
11:49:54.398494 64.231.80.147.1510 > 67.69.240.40.smtp: . ack 1 win 65535 (DF)
11:49:54.930162 67.69.240.40.smtp > 64.231.80.147.1510: P 1:36(35) ack 1 win 16944 (DF)
11:49:54.931071 64.231.80.147.1510 > 67.69.240.40.smtp: P 1:17(16) ack 36 win 65500 (DF)
11:49:54.940799 67.69.240.40.smtp > 64.231.80.147.1510: . ack 17 win 16928 (DF)
11:49:54.941263 67.69.240.40.smtp > 64.231.80.147.1510: P 36:99(63) ack 17 win 16944 (DF)
11:49:54.941722 64.231.80.147.1510 > 67.69.240.40.smtp: P 17:53(36) ack 99 win 65437 (DF)
11:49:54.952369 67.69.240.40.smtp > 64.231.80.147.1510: . ack 53 win 16908 (DF)
11:49:54.952956 67.69.240.40.smtp > 64.231.80.147.1510: P 99:138(39) ack 53 win 16944 (DF)
11:49:54.953348 64.231.80.147.1510 > 67.69.240.40.smtp: P 53:88(35) ack 138 win 65398 (DF)
11:49:54.963742 67.69.240.40.smtp > 64.231.80.147.1510: . ack 88 win 16909 (DF)
11:49:54.964534 67.69.240.40.smtp > 64.231.80.147.1510: P 138:181(43) ack 88 win 16944 (DF)
11:49:54.964891 64.231.80.147.1510 > 67.69.240.40.smtp: P 88:123(35) ack 181 win 65355 (DF)
11:49:54.974825 67.69.240.40.smtp > 64.231.80.147.1510: . ack 123 win 16909 (DF)
11:49:54.976038 67.69.240.40.smtp > 64.231.80.147.1510: P 181:224(43) ack 123 win 16944 (DF)
11:49:54.976398 64.231.80.147.1510 > 67.69.240.40.smtp: P 123:163(40) ack 224 win 65312 (DF)
11:49:54.986675 67.69.240.40.smtp > 64.231.80.147.1510: . ack 163 win 16904 (DF)
11:49:54.987982 67.69.240.40.smtp > 64.231.80.147.1510: P 224:272(48) ack 163 win 16944 (DF)
11:49:54.988360 64.231.80.147.1510 > 67.69.240.40.smtp: P 163:197(34) ack 272 win 65264 (DF)
11:49:54.998390 67.69.240.40.smtp > 64.231.80.147.1510: . ack 197 win 16910 (DF)
11:49:55.000708 67.69.240.40.smtp > 64.231.80.147.1510: P 272:314(42) ack 197 win 16944 (DF)
11:49:55.001061 64.231.80.147.1510 > 67.69.240.40.smtp: P 197:232(35) ack 314 win 65222 (DF)
11:49:55.012314 67.69.240.40.smtp > 64.231.80.147.1510: . ack 232 win 16909 (DF)
11:49:55.013110 67.69.240.40.smtp > 64.231.80.147.1510: P 314:357(43) ack 232 win 16944 (DF)
11:49:55.013454 64.231.80.147.1510 > 67.69.240.40.smtp: P 232:274(42) ack 357 win 65179 (DF)
11:49:55.023617 67.69.240.40.smtp > 64.231.80.147.1510: . ack 274 win 16902 (DF)
11:49:55.024483 67.69.240.40.smtp > 64.231.80.147.1510: P 357:407(50) ack 274 win 16944 (DF)
11:49:55.024833 64.231.80.147.1510 > 67.69.240.40.smtp: P 274:311(37) ack 407 win 65129 (DF)
11:49:55.035668 67.69.240.40.smtp > 64.231.80.147.1510: . ack 311 win 16907 (DF)
11:49:55.036122 67.69.240.40.smtp > 64.231.80.147.1510: P 407:452(45) ack 311 win 16944 (DF)
11:49:55.036479 64.231.80.147.1510 > 67.69.240.40.smtp: P 311:317(6) ack 452 win 65084 (DF)
11:49:55.046549 67.69.240.40.smtp > 64.231.80.147.1510: . ack 317 win 16938 (DF)
11:49:55.046804 67.69.240.40.smtp > 64.231.80.147.1510: P 452:466(14) ack 317 win 16944 (DF)
11:49:55.055311 64.231.80.147.1510 > 67.69.240.40.smtp: . 317:1729(1412) ack 466 win 65070 (DF)
11:49:55.055413 64.231.80.147.1510 > 67.69.240.40.smtp: P 1729:2982(1253) ack 466 win 65070 (DF)
11:49:55.082522 67.69.240.40.smtp > 64.231.80.147.1510: . ack 1729 win 15532 (DF)
11:49:55.082748 64.231.80.147.1510 > 67.69.240.40.smtp: P 2982:2987(5) ack 466 win 65070 (DF)
11:49:55.097696 67.69.240.40.smtp > 64.231.80.147.1510: . ack 2982 win 15691 (DF)
11:49:55.098245 67.69.240.40.smtp > 64.231.80.147.1510: . ack 2987 win 16939 (DF)
11:49:55.106587 67.69.240.40.smtp > 64.231.80.147.1510: P 466:500(34) ack 2987 win 16944 (DF)
11:49:55.216709 64.231.80.147.1510 > 67.69.240.40.smtp: . ack 500 win 65036 (DF)
11:49:55.617381 64.231.80.147.domain > 198.235.216.135.domain:  53703+ A? gbl11.lb-revsci.net. (37) (DF)
11:49:55.647563 198.235.216.135.domain > 64.231.80.147.domain:  53703* 1/0/0 A 38.96.134.245 (53) (DF)

47 packets received by filter
0 packets dropped by kernel
I am not sure how this is supposed to tell me why my DNS lookups are slow.

My Squid Cache manager is much easier to read for a networking idiot like me: (I've edited the non-relevant stuff out)

Code:
Connection information for squid:
	Number of clients accessing cache:	33
	Number of HTTP requests received:	531993
	HTTP requests per minute:	16.0
	Select loop called: 650845887 times, 3.069 ms avg

Median Service Times (seconds)  5 min    60 min:
	HTTP Requests (All):   0.09219  0.08729
	Cache Misses:          0.22004  0.16775
	Cache Hits:            0.01745  0.01847
	Near Hits:             0.17711  0.14252
	Not-Modified Replies:  0.01098  0.00678
	DNS Lookups:           9.70242  9.70242 <-******
	ICP Queries:           0.00000  0.00000
This is telling me DNS lookups are taking 10 seconds on average!!! Why and how do I find a better DNS server?

I couldn't find any reference to DNS in the httpd.conf file you specified.

Thanks.

Last edited by Avatar; 10-19-2006 at 11:59 AM.
 
Old 10-24-2006, 12:36 PM   #6
Avatar
Member
 
Registered: May 2001
Location: Canada
Distribution: old ones
Posts: 532

Original Poster
Rep: Reputation: 30
Anyone? I need help with tcpdump.
 
Old 10-24-2006, 03:07 PM   #7
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,414

Rep: Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967
well basically you can the DNS lookups here:
Code:
11:49:55.617381 64.231.80.147.domain > 198.235.216.135.domain:  53703+ A? gbl11.lb-revsci.net. (37) (DF)
11:49:55.647563 198.235.216.135.domain > 64.231.80.147.domain:  53703* 1/0/0 A 38.96.134.245 (53) (DF)
you make a request on the first line, and the response came back on the second. it came back within 50 milliseconds, which is great, and it came back from a single request, so you did not have to ask twice. int he first example in the trace, you can see the request took 600 milliseconds which is still pretty quick but i'd assume it took much longer as it didn't have it cached in that server so had to go upstream for it. not sure where to really go from there, those examples you've seen look absolutely fine. i would suggest exploring tcpdump further (really not sure why people have trouble understanding it myself...) and filter just on port 53, and leave it running on the squid box. if you leave it for more than 5 minutes you'll see every single request that box does to DNS on the wire and know exactly what happened. one thing i could suggest is that you have additional entries higher in the list on resolv.conf which are not routing out the same interface and are failing. e.g. maybe you even have something like 127.0.0.1 as an entry...

if you run "tcpdump -vn port 53" and then see what happens. one thing to note is that with the -n there no dns lookups are done on the trffic here, so the result will show *instantly*. as such if, when you go to a new page not in your local dns cache and it goes upstream for that address, the tcpdump output would also change immediately. if it takes ooh... 9.7 seconds before the tcpdump output shows a dns request then all that time somethign else has been going on and your real dns servers are not going to be at fault at all.
 
Old 10-24-2006, 04:40 PM   #8
Avatar
Member
 
Registered: May 2001
Location: Canada
Distribution: old ones
Posts: 532

Original Poster
Rep: Reputation: 30
Here's the reason why tcpdump is hard to understand.
1. I didn't know DNS requests were made on port 53. Now I know.
2. THe fields in the results are NOT self-explanatory. Well, some are, but the results look like Greek to me.

OK here are some results.
Code:
16:36:51.103573 64.231.95.197.32772 > 142.77.1.1.53:  [udp sum ok] 7229+ A? www1.ca.dell.com. [|domain] (DF) (ttl 64, id 0, len 62)
16:36:51.147537 142.77.1.1.53 > 64.231.95.197.32772:  7229 2/4/4 www1.ca.dell.com. CNAME www1.ins.dell.com., www1.ins.dell.com. (248) (DF) (ttl 242, id 35699, len 276)
16:36:51.690304 64.231.95.197.1031 > 142.77.1.1.53:  [udp sum ok] 11171+ A? img.dell.com. [|domain] (ttl 127, id 12640, len 58)
16:36:51.734132 142.77.1.1.53 > 64.231.95.197.1031:  11171 2/4/4 img.dell.com. CNAME img.ins.dell.com., img.ins.dell.com. (243) (DF) (ttl 242, id 35700, len 271)
16:36:51.904080 64.231.95.197.53 > 198.235.216.134.53:  [udp sum ok] 36391+ [1au] A? img.dell.com. . OPT  UDPsize=2048 (41) (DF) (ttl 64, id 0, len 69)
16:36:53.023657 64.231.95.197.53 > 198.235.216.135.53:  [udp sum ok] 39997+ A? www.tdcanadatrust.com. [|domain] (DF) (ttl 64, id 0, len 67)
16:36:53.043168 198.235.216.135.53 > 64.231.95.197.53:  39997 1/2/2 www.tdcanadatrust.com. A 142.205.233.230 (133) (DF) (ttl 247, id 506, len 161)
16:36:53.558991 64.231.95.197.53 > 198.235.216.134.53:  [udp sum ok] 55461+ [1au] A? as00.estara.com. . OPT  UDPsize=2048 (44) (DF) (ttl 64, id 0, len 72)
16:36:58.281876 64.231.95.197.53 > 198.235.216.134.53:  [udp sum ok] 21468+ [1au] A? easyweb.tdcanadatrust.com. . OPT  UDPsize=2048 (54) (DF) (ttl 64, id 0, len 82)
16:37:00.353631 64.231.95.197.53 > 198.235.216.135.53:  [udp sum ok] 54424+ A? www1.ca.dell.com. [|domain] (DF) (ttl 64, id 0, len 62)
16:37:00.373038 198.235.216.135.53 > 64.231.95.197.53:  54424 2/4/4 www1.ca.dell.com. CNAME www1.ins.dell.com., www1.ins.dell.com. (240) (DF) (ttl 247, id 507, len 268)
16:37:00.373500 64.231.95.197.53 > 198.235.216.134.53:  [udp sum ok] 29955+ [1au] A? www1.ins.dell.com. . OPT  UDPsize=2048 (46) (DF) (ttl 64, id 0, len 74)
16:37:02.193568 64.231.95.197.32772 > 142.77.1.1.53:  [udp sum ok] 7230+ A? img.dell.com. [|domain] (DF) (ttl 64, id 0, len 58)
16:37:02.282586 142.77.1.1.53 > 64.231.95.197.32772:  7230 2/4/4 img.dell.com. CNAME img.ins.dell.com., img.ins.dell.com. (247) (DF) (ttl 242, id 35701, len 275)
16:37:03.937959 64.231.95.197.1031 > 142.77.1.1.53:  [udp sum ok] 46509+ A? img.dell.com. [|domain] (ttl 127, id 12740, len 58)
16:37:03.948609 64.231.95.197.1135 > 142.77.1.1.53:  [udp sum ok] 21421+ A? img.dell.com. [|domain] (ttl 127, id 12741, len 58)
16:37:03.990244 142.77.1.1.53 > 64.231.95.197.1031:  46509 2/4/4 img.dell.com. CNAME img.ins.dell.com., img.ins.dell.com. (243) (DF) (ttl 242, id 35702, len 271)
16:37:03.991692 142.77.1.1.53 > 64.231.95.197.1135:  21421 2/4/4 img.dell.com. CNAME img.ins.dell.com., img.ins.dell.com. (243) (DF) (ttl 242, id 35703, len 271)
16:37:06.069729 64.231.95.197.1031 > 142.77.1.1.53:  [udp sum ok] 45231+ A? pbar.us.dell.com. [|domain] (ttl 127, id 12919, len 62)
16:37:06.113558 142.77.1.1.53 > 64.231.95.197.1031:  45231 2/4/4 pbar.us.dell.com. CNAME pbar.ins.dell.com., pbar.ins.dell.com. (248) (DF) (ttl 242, id 35704, len 276)
16:37:06.179049 64.231.95.197.53 > 198.235.216.134.53:  [udp sum ok] 42004+ [1au] A? pbar.us.dell.com. . OPT  UDPsize=2048 (45) (DF) (ttl 64, id 0, len 73)
16:37:09.883653 64.231.95.197.53 > 198.235.216.135.53:  [udp sum ok] 21002+ A? lt.ins.dell.com. [|domain] (DF) (ttl 64, id 0, len 61)
16:37:09.903633 198.235.216.135.53 > 64.231.95.197.53:  21002 2/4/4 lt.ins.dell.com. A 143.166.170.16, lt.ins.dell.com. A 143.166.11.23 (232) (DF) (ttl 247, id 508, len 260)
16:37:11.913628 64.231.95.197.53 > 198.235.216.135.53:  [udp sum ok] 43269+ A? img.dell.com. [|domain] (DF) (ttl 64, id 0, len 58)
16:37:11.933186 198.235.216.135.53 > 64.231.95.197.53:  43269 2/4/4 img.dell.com. CNAME img.ins.dell.com., img.ins.dell.com. A 143.166.224.238 (235) (DF) (ttl 247, id 509, len 263)
16:37:11.933649 64.231.95.197.53 > 198.235.216.134.53:  [udp sum ok] 29668+ [1au] A? img.ins.dell.com. . OPT  UDPsize=2048 (45) (DF) (ttl 64, id 0, len 73)
16:37:13.573632 64.231.95.197.53 > 198.235.216.135.53:  [udp sum ok] 14834+ A? as00.estara.com. [|domain] (DF) (ttl 64, id 0, len 61)
16:37:13.655446 198.235.216.135.53 > 64.231.95.197.53:  14834 2/4/4 as00.estara.com. A 69.25.47.120, as00.estara.com. A 66.155.171.120 (205) (DF) (ttl 247, id 510, len 233)
16:37:15.748777 64.231.95.197.1031 > 142.77.1.1.53:  [udp sum ok] 57256+ A? catalog.dell.com. [|domain] (ttl 127, id 12928, len 62)
16:37:15.896954 142.77.1.1.53 > 64.231.95.197.1031:  57256 2/4/4 catalog.dell.com. CNAME[|domain] (DF) (ttl 242, id 35705, len 287)
16:37:15.913922 64.231.95.197.53 > 198.235.216.134.53:  [udp sum ok] 3640+ [1au] A? catalog.dell.com. . OPT  UDPsize=2048 (45) (DF) (ttl 64, id 0, len 73)
16:37:16.233563 64.231.95.197.32772 > 142.77.1.1.53:  [udp sum ok] 7232+ A? pbar.us.dell.com. [|domain] (DF) (ttl 64, id 0, len 62)
16:37:16.277326 142.77.1.1.53 > 64.231.95.197.32772:  7232 2/4/4 pbar.us.dell.com. CNAME pbar.ins.dell.com., pbar.ins.dell.com. (248) (DF) (ttl 242, id 35706, len 276)
Now, it seems the first field is the time the activity took place, then IP of the sender, direction the packet is going, IP of the reciever (and port, I assume), <don't know>, <don't know>, the resolved domain name, the rest I don't know.

I guess I am looking for the lines with the matching domain names, and their times?

Obviously, my boss is thinknig of buying a Dell, and it looks like the Internet is working nice and fast. (Am I right?)

Last edited by Avatar; 10-24-2006 at 04:42 PM.
 
Old 10-26-2006, 08:35 AM   #9
tola555
LQ Newbie
 
Registered: Sep 2005
Posts: 20

Rep: Reputation: 0
use dig to see how long query takes.

Code:
 dig www.linuxquestions.org 127.0.0.1
where 127.0.0.1 is your dns server. (I have caching dns server/proxy). Try some /etc/resolv.conf servers too.
OK, now output:
Code:
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 26 15:27:20 2006
;; MSG SIZE  rcvd: 102
It takes 1ms to resolve on the second,third etc time. I use power dns, its easy to conf. I believe named is not hard to conf too. I suggest you to have caching dns if you have lot of client accessing www. And your http etc logs are lookuped a lot faster.

I didn't read out where your problem is but take some tests with dig and put them here.

Last edited by tola555; 10-26-2006 at 08:38 AM.
 
Old 10-26-2006, 09:49 AM   #10
Avatar
Member
 
Registered: May 2001
Location: Canada
Distribution: old ones
Posts: 532

Original Poster
Rep: Reputation: 30
Hmmmmm very interesting....

I did a quick little scan, exactly like my post above but with the option -ttt on tcpdump (I've been studying the man pages) to use a delta instead of a timestamp. I opened my MSIE which defaults to google as the home page. It appears that it took over 10 seconds to load (2nd last line), although I can't tell which IP address is causing the delay.

Code:
000000 64.231.95.197.4203 > 142.77.1.1.53:  [udp sum ok] 9279+ A? www.google.ca. [|domain] (ttl 127, id 47221, len 59)
045516 142.77.1.1.53 > 64.231.95.197.4203:  9279 5/6/6 www.google.ca. CNAME www.google.com., www.google.com. (319) (DF) (ttl 242, id 40361, len 347)
005723 64.231.95.197.53 > 198.235.216.134.53:  [udp sum ok] 37018+ [1au] A? www.l.google.com. . OPT  UDPsize=2048 (45) (DF) (ttl 64, id 0, len 73)
10. 035241 64.231.95.197.32772 > 142.77.1.1.53:  [udp sum ok] 11691+ A? www.google.ca. [|domain] (DF) (ttl 64, id 0, len 59)
043568 142.77.1.1.53 > 64.231.95.197.32772:  11691 5/6/6 www.google.ca. CNAME www.google.com., www.google.com. (319) (DF) (ttl 242, id 40362, len 347)
This problem didn't occur when I used dig. (Though, my agonizingly slow Internet is an intermittent problem it seems, anyway).

Code:
; <<>> DiG 9.2.1 <<>> www.google.ca 192.168.1.1
;; Query time: 84 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 09:46:44 2006
;; MSG SIZE  rcvd: 450

;; Query time: 73 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 09:46:44 2006
;; MSG SIZE  rcvd: 448
Code:
; <<>> DiG 9.2.1 <<>> www.dell.com 192.168.1.1
;; Query time: 354 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 09:48:07 2006
;; MSG SIZE  rcvd: 254

;; Query time: 523 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 09:48:08 2006
;; MSG SIZE  rcvd: 448
And that doesn't really seem that bad. I'm going to try it some more here....
 
Old 10-26-2006, 10:21 AM   #11
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,414

Rep: Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967Reputation: 1967
the only thing of interest there is that your system goes out to 198.235.216.134 when the 10 second delay occurs, as opposed to 142.77.1.1 when it's fine. i'd look towards that particular name server being to blame possibly...? can you dig against 198.235.216.134 ?
 
Old 10-26-2006, 11:55 AM   #12
Avatar
Member
 
Registered: May 2001
Location: Canada
Distribution: old ones
Posts: 532

Original Poster
Rep: Reputation: 30
Here's a couple of results.

Code:
; <<>> DiG 9.2.1 <<>> www.jobbank.gc.ca 198.235.216.134
;; Query time: 317 msec
;; SERVER: 216.94.106.2#53(216.94.106.2)
;; WHEN: Thu Oct 26 11:49:58 2006
;; MSG SIZE  rcvd: 151

;; Query time: 696 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 11:49:59 2006
;; MSG SIZE  rcvd: 452
Code:
; <<>> DiG 9.2.1 <<>> www.google.ca 198.235.216.134
;; Query time: 178 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 11:50:09 2006
;; MSG SIZE  rcvd: 450

;; Query time: 594 msec
;; SERVER: 216.94.106.2#53(216.94.106.2)
;; WHEN: Thu Oct 26 11:50:11 2006
;; MSG SIZE  rcvd: 108
And for 142.77.1.1:

Code:
; <<>> DiG 9.2.1 <<>> www.jobbank.gc.ca 142.77.1.1
;; Query time: 166 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 11:52:42 2006
;; MSG SIZE  rcvd: 454

;; Query time: 133 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 11:52:42 2006
;; MSG SIZE  rcvd: 447
Code:
; <<>> DiG 9.2.1 <<>> www.google.ca 142.77.1.1
;; Query time: 223 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 11:53:46 2006
;; MSG SIZE  rcvd: 450

;; Query time: 102 msec
;; SERVER: 66.235.251.147#53(66.235.251.147)
;; WHEN: Thu Oct 26 11:53:46 2006
;; MSG SIZE  rcvd: 447
It looks like you might be right, 198.235.216.134 is slower than 142.77.1.1.
 
Old 10-26-2006, 01:11 PM   #13
tola555
LQ Newbie
 
Registered: Sep 2005
Posts: 20

Rep: Reputation: 0
not too bad.

but output of
Code:
<<>> DiG 9.2.1 <<>> www.google.ca 192.168.1.1
says you dont have caching-nameserver on your pc. You should do some caching to speed up your network
 
Old 10-26-2006, 01:30 PM   #14
rocksniffer
Member
 
Registered: Apr 2005
Location: Houston
Distribution: mandrake
Posts: 79

Rep: Reputation: 15
Most of the above is way over my head, but I had slow lookup times with a stand alone
linux box and earthlink provider, cable.
I found that reordering the dns addresses in the resolv.conf file putting the fast
one on top solved the problem. On a reboot, though, the original order was reset. There is a
way to slove that but I don't recall.
 
Old 10-26-2006, 05:39 PM   #15
tola555
LQ Newbie
 
Registered: Sep 2005
Posts: 20

Rep: Reputation: 0
you have to edit interface conf
in debian it is /etc/network/interfaces
Code:
auto lo eth0
iface eth0 inet static
        address 10.0.0.2
        netmask 255.255.255.0
        network 10.0.0.0
        broadcast 10.0.0.255
        gateway 10.0.0.1
        dns-nameservers 10.0.0.1
        dns-search homenet
and then hit /etc/init.d/networking restart or reload whatever works for you. (in Debian)

for more info
Code:
pc1:~$ man interfaces
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Webalizer with DNS lookups jnichel Linux - Software 21 01-23-2009 12:13 PM
continued slow dns lookups on Fedora Core 5 nshewmaker Linux - Networking 13 12-19-2006 04:45 PM
slow DNS lookups using Novatel V620 gpetme Linux - Wireless Networking 4 05-06-2006 11:55 AM
DNS Lookups Slow kwiksand Linux - Networking 0 11-15-2004 05:52 AM
Caching DNS lookups vikasa Linux - Networking 0 06-26-2003 01:30 PM


All times are GMT -5. The time now is 05:00 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration