[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian squeeze (testing) dns problems



Hugh Lawson writes:
> Bob Cox <debian-user@lists.bobcox.com> writes:
> 
> [ snip ]

> fetchmail: getaddrinfo("pop-server.triad.rr.com","pop3") error: Name or

I tried the following:

host -a pop-server.triad.rr.com

to see what sort of DNS lookup we get:

Trying "pop-server.triad.rr.com"


pop-server.triad.rr.com. 232	IN	A	71.74.56.73

triad.rr.com.		3532	IN	NS	dns-sec-01.southeast.rr.com.
triad.rr.com.		3532	IN	NS	dns-pri-01.southeast.rr.com.

dns-pri-01.southeast.rr.com. 3007 IN	A	24.25.4.103
dns-sec-01.southeast.rr.com. 3007 IN	A	24.25.4.104

pop-server.triad.rr.com's DNS TTL or time to live is only about
5 minutes. This is the amount of time that your cache will
remember it after having looked it up. Actually, in my example,
it is 232 seconds or 2 minutes and 12 seconds so it could be
anything up to around 5 minutes. There is nothing wrong with
that if you have good communications with one of the DNS's shown
as authoritative for that domain. If you don't, you've got an
intermittent problem as your resolver is doing exactly what it
is supposed to do. It remembers for up to 5 minutes and then
does another lookup after that to refresh itself and, if it
can't contact one of the DNS's listed there, the lookup fails.

	The short TTL for the pop server may be a load balancing
strategy so this isn't necessarily a bad thing but it turns bad
if connectivity to the authoritative DNS's or functionality of
the DNS's is poor.

My apology if this sounds like no help, but it may be an
explanation of why the lookup sometimes fails.

Martin McCormick WB5AGZ  Stillwater, OK 
Systems Engineer
OSU Information Technology Department Telecommunications Services Group


Reply to: