You are not logged in.

#1 2004-07-30 15:52:06

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Slow "resolving name..." [fixed]

After some recent upgrades (-Syu) my ArchLinux system started to suffer of loooong "resolving name..." times.
A <dig www.bbc.com> command revealed a 3.5s query time but it actually stayed 9secs for the entire command.
I've tried:
1. using localhost (running bind) in /etc/resolv.conf (with/without forwarding to my ISP DNS server)
2. using my ISP DNS servers in /etc/resolv.conf
3. adding "alias net-pf-10 off" in /etc/modprobe.conf since I found out on the net that there's a bug in the IPv6 implementation in kernel 2.6.x
4. turning off/on the firewall
5. combinations of the above settings
+ reinstall bind (use default settings)

Subsequent queries running local bind (& proper settings in /etc/resolv.conf) returned <10ms query times, but the browser's resolving times haven't changed.
I've tried Firefox 0.9.1, Konqueror (KDE 3.2.3), elinks (latest version) - got the same long resolve times.

Lots of thanks.

P.S. I've lost half of the day (11:00 - 18:45) trying to figure out what's wrong with it but still no luck
P.S.2. the windows installation I have on the same computer (which I haven't started since I moved to ArchLinux 3 months ago) is lightning fast on the net...

Offline

#2 2004-07-30 17:03:48

xerxes2
Member
From: Malmoe, Sweden
Registered: 2004-04-23
Posts: 1,249
Website

Re: Slow "resolving name..." [fixed]

do you have your hostname in /etc/hosts ?


arch + gentoo + initng + python = enlisy

Offline

#3 2004-07-30 18:45:02

marin_linuxer
Member
From: San Rafael, CA U.S.A.
Registered: 2003-09-03
Posts: 111
Website

Re: Slow "resolving name..." [fixed]

Watch-out for the IPv6 components in the recent Mozilla code.  If you have any IPv6 services running(net-pf-10/ipv6), then, that may be the problem.


-- Linux!  Isn't it time?

Offline

#4 2004-07-30 21:14:59

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: Slow "resolving name..." [fixed]

1. the /etc/hosts file looks good
2. it's not a Mozilla thing, it happens in all the browsers

It seems that the problem is indeed related to IPv6. I've (slowly) browsed the bug report in firefox about slow resolves in 0.8, got the .c file from there, compiled it, run it and it indeed returned an error at the IPv6 resolve section.

I've set network.dns.disableIPv6 to true in firefox but haven't seen much change. While running ethereal as root I've noticed that AAAA queries are no longer done with that option turned on.
I've configured the local bind to work also on IPv6 so that it answers the AAAA queries in all the programs (konqueror and so on). The slow resolve didn't fix yet, although it looked like it was solved a few moments ago.

Unfortunately, I can't run sudo ethereal in a normal user KDE session because of some display permissions (haven't hacked X properly to learn how to do this yet).

If anyone has more ideas, I'd be happy to hear them out.
One more idea I'm going to try is to find out some DNS server supporting AAAA name lookups...

IceRAM

Offline

#5 2004-07-30 21:23:34

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: Slow "resolving name..." [fixed]

IceRAM wrote:

(haven't hacked X properly to learn how to do this yet).

xhost +localhost (as user) before running sudo should do the trick

If anyone has more ideas, I'd be happy to hear them out.

Do you need IPv6 support? If not, you could try turning it off in the kernel. Or is that the problem?

Dusty

Offline

#6 2004-07-30 23:01:56

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: Slow "resolving name..." [fixed]

Ante-Scriptum: if you're really borred and want to read some stories about my .ro ISP, keep reading - if not, you should know that this problem is fixed (solution - in the end).

Well... you won't believe the reason... kind of strange but... true.

This entire day (& last night) my ISP 'played' with the new cable modems (which I've received in free custody).
[the old Lancity modems were changed with new ones, offering double speed, increased traffic (almost x2), & VoIP (including minutes) + phone in custody - at the same cost as in the previous contract - this is what I call a great offer (at least for Romania)].

I've noticed a strange thing at my modem after firt plugging it in (of course it didn't sync from the begining and I had to give some phonecalls to make it work): the Receive and the PC leds were always blinking. ethereal revealed that the ARP traffic was routed all to the PC and that's why both leds were blinking (kind of a useless blinking IMO) - I've reported this to the ISP. Last night it got unsync-ed. It didn't sync back automatically. The slow "resolving name..." was also present then together with a "can't ping anything" feeling. This morning, it got unsync-ed again. After resetting it by hand (unplug & plug), I've noticed that the Receive led does not blink anymore (I've said to myself: good, software upgrade.. now they've learned something.. but wait.. why does the PC led keep blinking... why? because the ARP packages still get to the PC... maybe next time...). The phone was no longer working, but it got fixed after a phonecall. Then I found out: on software rewrites the modem can't get resynced automatically, and it needs a cold reset (oh joy, at least I was told what to do from now on). They couldn't help me figure out why I couldn't ping anything from either Linux or Windows.

Then, the entire day I tried making my Linux box browse the net as fast as the Windows one.
My ISP gave me 2 DNS servers to use (primary & secondary), just like any ISP would do (I think). I've updated them in Linux, because I use Linux for 3 months. This morning when I tested the remainings of Windows I've only switched the IP & Gateway and saw that it works. I said to myself: there's no need to change the DNS too, because it will work anyhow. That being said, I've returned to Linux, I've written this topic's first post.. and tried to make it work again.

This evening I've started packet sniffing with ethereal. I checked all the packages that went through loopback (I remained to my config with bind daemon) - nothing wrong. I've moved to all the port 53 udp packages going through eth0 (external NIC). Tested a few sites and guess what I found. The first DNS never responded. If the 1st DNS does not respond, after 5 secs, a new query is launched, adding the domain name to the name that was first looked for. After ~10secs of no response, the 2nd DNS server is used. Just imagine that there's more than one server that needs to be checked when loading a webpage. Imagine now how much it would take to start downloading something.

Of course, I couldn't check the DNS to see if it's working with ping, because I had NO PING (they probably filtered it (or changed the software) and they don't know it, yet). After removing the 1st DNS from the forwarders list in /etc/named.conf, Firefox regained its speed. It was an incredible feeling. It was like it has never been so fast.

I've lost one day just to see that the ISP gave me a non-working DNS that slowed my entire network.

Now, I've got some questions:
1. I've configured my bind daemon to act as a caching server, forwarding uncached names to the ISP nameserver(s). Unfortunately, I've seen that no matter what I do, the ISP nameserver is always used. Does anyone have a good named.conf file that ensures the fact that the forwarders won't be used except when the cached entries are expired?
2. why is the non working first DNS still used if Linux finds out that the 2nd  one is good? The 2nd one should be used and, after a while, the 1st should be checked again, to see if it started working.

Some good things I've learned in this experience:
1. use ethereal whenever you have some network problem
2.

Dusty wrote:
IceRAM wrote:

(haven't hacked X properly to learn how to do this yet).

xhost +localhost (as user) before running sudo should do the trick

Wow.. that was easy... 10x Dusty

Also, I don't need IPv6, but compiling a kernel on my P3 450MHz would take too much time. I preffer turning it off in /etc/modprobe.conf.

Lots of thanks to others who expressed their opinions in this matter.

Offline

#7 2004-07-30 23:20:38

kakabaratruskia
Member
From: Santiago, Chile
Registered: 2003-08-24
Posts: 596

Re: Slow "resolving name..." [fixed]

How did you make bind act as a caching server?. I tryed a while ago, and could never get it working, even though I read lot's of guides (maybe I'm just stupid...)


And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.

Offline

#8 2004-07-31 17:44:55

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: Slow "resolving name..." [fixed]

kakabaratruskia wrote:

How did you make bind act as a caching server?. I tryed a while ago, and could never get it working, even though I read lot's of guides (maybe I'm just stupid...)

Sorry for taking this long to answer. I had to test it first to see that it really caches DNS entries.

Here's the tutorial I've used.
http://www.faqs.org/docs/securing/chap21sec164.html
+ one small correction

[root@deep]# dig @.aroot-servers.net . ns > db.cache

should be

[root@deep]# dig @f.root-servers.net . ns > db.cache

(I used F instead of A because that's how root.hint in Arch package is generated - I don't know the difference, yet)

I changed everything mentioned there, I've even changed the original filenames. That tutorial is not Arch-oriented. Some of the files exist also in the bind daemon package, but with other filenames. The content of some files is somehow different, that's why I've used what's everything that was mentioned there. Another reason for doing this was the fact that I don't have much time learning each and every option of bind.

After some ethereal tests, I've found out that caching really works. A DNS entry remains in cache as long as it is marked when it first reaches your computer (it has some sort of TTL assigned). Check it out with "dig <hostname>". If you keep entering the command you'll see that one parameter displayed there keeps dropping. That's the current TTL.

+ Don't forget to use

nameserver localhost

in /etc/resolv.conf

HTH

IceRAM

Offline

#9 2004-07-31 21:10:18

kakabaratruskia
Member
From: Santiago, Chile
Registered: 2003-08-24
Posts: 596

Re: Slow "resolving name..." [fixed]

I've configured it, and web browsing seems fine, but I can't test it. When I try "dig www.archlinux.org", it gives me this error:
; <<>> DiG 9.2.3 <<>> www.archlinux.org
;; global options:  printcmd
;; connection timed out; no servers could be reached

So I don't know if it's working.

EDIT: Pacman does not work either, so I'll have to go back to the old way, till I find a solution.


And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.

Offline

#10 2004-07-31 21:25:09

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: Slow "resolving name..." [fixed]

1. Make sure the DNS servers you used in the "forward(ers)" lines actually work.
2. Don't forget to put "nameserver localhost" in /etc/resolv.conf.
3. restart named after you change the named.conf with "/etc/rc.d/named restart"
+ try again

Test with ethereal binded to the external interface (the one used to connect to the DNS servers). Don't forget to use filter: "port udp 53" or "udp port 53", I don't remember exactly.

IceRAM

Offline

#11 2004-07-31 21:39:28

kakabaratruskia
Member
From: Santiago, Chile
Registered: 2003-08-24
Posts: 596

Re: Slow "resolving name..." [fixed]

I did not have named running  :oops:  :oops:   :oops:
With named running, it workes fine.

Another thing, is there a way to stop dhcpcd rewriting my /etc/resolv.conf everytime I reboot or do /etc/rc.d/network restart


And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.

Offline

#12 2004-07-31 22:31:31

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: Slow "resolving name..." [fixed]

kakabaratruskia wrote:

Another thing, is there a way to stop dhcpcd rewriting my /etc/resolv.conf everytime I reboot or do /etc/rc.d/network restart

Hmm... using as nameserver your INTERNAL-IP in the dhcpd config would solve your problem?
(I don't use DHCP internally in my network - yet - because I have only one other computer besides the one I'm using right now)

Another idea would be to copy the network (or any other script) in /etc/rc.d/ and create a small daemon for you that would change /etc/resolv.conf to what you want. It's really easy.
I've created a small daemon running a personal script [infinite loop that checks if the other computer inside my net is online + anyone is logged at this computer and, if in ~10 mins the situation does not change, it shutdowns my computer (gateway)]. I think I've also packed it and installed it with pacman.

Offline

#13 2004-07-31 22:51:22

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: Slow "resolving name..." [fixed]

I think I've understood your post wrongly.
You said dhcpCd. Haven't seen the c there.

In this case, I think that only the 2nd solution applies. Or, maybe dhcpcd has a config option somewhere to ignore the DNS setting provided by the DHCP server, I don't know.

IceRAM

Offline

Board footer

Powered by FluxBB