Hugh Lawson writes:
> Bob Cox <debian-u...@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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
