DNSBL helper not answering

Vernon Schryver vjs@calcite.rhyolite.com
Thu Nov 23 20:43:38 UTC 2006

> From: Daniel Gehriger 

> > That is not exactly what I meant to say.  The race I suspect but have
> > not verified might happen 50% of the time to the first 5 mail messages
> > that arrive after at least 60 but fewer than 65 seconds of inactivity.

I've varified a race, but it affects only the first mail message with
after 60-65 seconds of inactivity with roughly 50% probability.  The
result of the race is that a single DNSBL request fails.

> It's probably something else then. Below is part of the mail log, so you 

Those log lines do not show that dccifd should have started another helper
process to wait for DNS answers.  They do show that after a helper dies
of boredom, other helpers do a lot of failing.  I think all of lines are
from helper processes complaining about DNS problems instead of the main
dccifd process, because the PIDs vary.  The other possibility, that the
main dccifd process is being very frequently restarted would imply
a bigger problem than DNSBL helpers not being restarted.

Does your resolver library not have _res.retry and _res.retrans like the
BIND resolver library?
Those log lines suggest a total DNS timeout of at least 1:23.  Unless the
per-URL and per-message timeouts are at least as long, there will be problems.
With ressolver timeouts of 83 seconds and shorter dccifd -B timeouts,
the main dccifd process will frequently decide that the helpers are stuck
and try to make new batches of helpers.

If your resolver library has _res.retry and _res.retrans,
then perhaps it does not have resolv.h and arpa/nameser.h.
What does include/dcc_config.h say about these?

The next version will not require that both resolv.h and arpa/nameser.h be
available when it tries to adjust the DNS timeouts, but only _res and

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.