BIND and UDP tuning

Ben Croswell ben.croswell at gmail.com
Thu Sep 27 16:06:27 UTC 2018


When we ran into UDP tuning issues on high traffic devices it presented as
silent discards rather than SERVFAIL.

On Thu, Sep 27, 2018, 12:04 PM Alex <mysqlstudent at gmail.com> wrote:

> Hi,
>
> > On Thu, Sep 27, 2018 at 10:53:25AM -0400, Alex wrote:
> > > Many of these values I've already tweaked and have had no effect on my
> > > SERVFAIL issues :-(
> >
> > If you are getting SERVFAILs from a BIND resolver you administer, then
> > it has responded to your query. If you turn up the log level to
> > something like -d 99, it'll print the steps that led to that SERVFAIL.
> > Usually you'll find something there that directs you to next steps.
> >
> > On this topic, my home resolver is also a stock packaged BIND version as
> > you, and I too see spurious SERVFAILs sometimes. I used to think this
> > was due to too much indirection, e.g., when named starts up and you run:
> >
> >     dig -x 176.9.81.50
>
> It doesn't typically happen when running from the command-line. It
> does occasionally happen, though. I usually run something like "dig
> +all +trace +nodnssec <hostname>". It sometimes times out in the
> middle, with something like "cannot resolve xyz host", which may even
> be one of the root servers.
>
> I also typically run it with "rndc trace 11" which shows me quite a
> bit of debugging info - too much to look through manually. With trace
> 99, I can imagine it being overwhelming amount of info. Do you have
> any ideas of what to look for? "query-errors"?
>
> Also, I also see other SERVFAIL errors that really are SERVFAIL errors
> - when querying the host manually, it still responds immediately with
> SERVFAIL.
>
> Thanks,
> Alex
>
>
>
> >
> > on a cold cache. However it seems to be returning SERVFAIL sometimes for
> > what should be a cached answer. I'll also turn up the debug logging and
> > watch it.
> >
> >                 Mukund
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180927/2a907783/attachment.html>


More information about the bind-users mailing list