Re: heard all the who-haha? (slow reverse DNS lookups)
On Tue, 12 Aug 1997, Kevin Traas wrote:
> >Have you checked the name server entries in /etc/resolv.conf? DNS
> >problems are often tracked down to this point.
>
> Yes, I have. I've got three entries in there. One is the local host entry
> as I'm running BIND. The other two are DNS Servers of my upstream provider.
> All here should be okay....
>
This is not the problem with mine either, I have only the following lines
in there;
search apana.org.au
nameserver 127.0.0.1
> I'm thinking there must be some problem with reverse name lookups or
> something. I'm no expert in this area, but what else can it be? Routing is
> definitely not a problem. Running "ping" before trying the telnet session
> returns "immediate" responses. Connecting from some remote hosts is no
> problem, otheres there is.....
>
I agree that it appears to be on reverse DNS lookups, so I think we can
eliminate the problem being in "who". In particular, it looks like named
is not caching reverse DNS lookups for very long, and then it is taking
a looong time on a cache miss. From an strace of "who" it looks like DNS
queries (on localhost port 53) are timing out and re-trying a few times
before they succeed.
> Is this lookup necessary? Is there a way to disable it?
>
As someone else has mentioned, ALL:PARANIOD in /etc/hosts.deny means
reverse DNS lookups occur on everything. However, taking this out only
reduces the symptoms, it doesn't fix the problem.
> Later,
>
> Kevin Traas Baan Business Systems
> Systems Analyst Langley, BC, Canada
> Kevin@Baan-BBS.CA (604) 882-8169
>
> >> >Debian 1.3.1 sports a who which many are saying is "slow" while others
> >> >are saying the slowness is due to slow named servers. Were there
> >> >any notable changes leading up the the /usr/bin/who which came with
> >> >shellutils 1.16-2?
> >>
> >> I've been experiencing problems with some people telnetting into my
> system.
> >> Many people don't have a problem, but others do.... The problem is that
> the
> >> telnet client says "connected"; however, there is no response from my
> system
> >> for 150 seconds - 2.5 minutes! Once the client finally gets the
> response,
> >> everything is fine from there. No more delays, no more problems.
> >>
> >> Putting the client IP/hostname into /etc/hosts resolves this problem;
> >> however, this is an impractical solution.
> >>
This is interesting. On my machine, even reverse lookups on hosts in
/etc/hosts have the same problem. The strace of "who" shows it reading
/etc/hosts, and then querying my local nameserver as well. I do have
"order hosts,bind" in my /etc/host.conf, but maybe the "multi on" line is
making it check both?
Are you sure it fixed it on your machine? Is it possible that when you
tried it you just fluked a couple of times when the lookup was in the
cache? On my system, I have to wait about 5 minutes between lookups to
get the delay (cache miss?).
> >> Any ideas?
>
My machine has not been that bad lately, but I have changed nothing. I
still notice the delays on a DNS cache miss, and they are still
happening regularly, but the delay is more like 3~30 seconds, down
from 1~3 minutes. This makes me think that the long responce time on a
cache miss may have paritaly had something to do with my upstream
nameservers. My /var/named/boot.options has the following lines;
forwarders 192.188.107.12 203.8.183.1
options forward-only
The first forwarder is very close (3 hops), but the second is further away
(6 hops). Today (a good day for DNS), the first has an average ping of
190ms, and the second 711ms. I'll try and get some stats on a bad DNS day.
I'm thinking that maybe there are some timeouts in "named" that are a bit
tight, causing it to fail and retry too often on slower connetions to
other nameservers.
This doesn't explain why;
1) "named" is not caching reverse DNS lookups for very long (does it cache
reverse and forward lookups seperately?)
2) reverse DNS lookups are going through nameservers for hosts found in
/etc/hosts.
ABO
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: