bind-8 trying to contact dead NSs
Bernhard K. Weisshuhn
Hi & a Happy New Year everybody,
excuse me if this is a faq, but I wasn't able to find anything usefull
about it, so I guess this is the place to ask.
We recently started logging traffic on our router and noticed that
bind-8.8.1 (Linux 2.0.33) seems to generate quite an amount of udp and
icmp-traffic trying to reach defunct nameservers.
Taken together the UDP-Queries and the ICMP-unreachable answers, this
adds up to about 5 kB of traffic per minute for two hosts running bind
trying to contact one fritzed nameserver.
Although your interpretation of "quite an amount of traffic" may differ,
traffic is expensive in germany, and I find it rather annoying to waste
several MBs of traffic just because of lazy admins somewhere outthere.
Last time this happened (gblnet.com), I had to hunt down the Admin-
Contact (quite a job, don't rely on whois!) and beg him to fix his
servers (Took several weeks until they were up again).
Now it happened again: Since 1/1/98 the NS for 163.10.0.0 has died. The
host unlp.unlp.edu.ar (163.10.0.67) is listed as authoritive nameserver
and seems to be alive so far, but doesn't seem to have a dns-server running.
Result: 8 UDP-Querys to 163.10.0.67:53 and 3 ICMP destination unreachables
coming back per minute.
Question One: Why does named try to contact them at all? I don't seem to
have any other traffic for net 163.10.0.0 sitting here (except for the
named-queries of course). Probably something about the cache.
Question Two: Can I reduce the rate and number of retries named attemts
to reach dead nameservers? Or better: Can I stop bind from trying to
reach these servers when there is no other traffic waiting for these
adresses anymore and only retry when there is some?
Wild speculation: Could this be a loop where the ICMP-unreachable reply
is attempted to be resolved for logging and therefore another query is
made? Could this be (*gasp*) a bug in bind?
Maybe I should add, that one of the bind-running hosts also works as an
IP-masquerading gateway, and the other one is on that masqueraded
network (using the first host as a forwarder).
Any help is appreciated, and excuse me if I misunderstood something very
basic.
regards,
Bernhard
--
Bernhard K. Weisshuhn b...@fu-berlin.de http://www.inf.fu-berlin.de/~weisshuh/
"Wichtiger als die Postmoderne ist eine moderne Post." (Manfred Bonitz)