BIND and UDP tuning

Lee ler762 at
Fri Sep 28 14:45:43 UTC 2018

On 9/28/18, Alex <mysqlstudent at> wrote:
> Hi,
> On Fri, Sep 28, 2018 at 12:18 AM Lee <ler762 at> wrote:
>> On 9/27/18, Alex <mysqlstudent at> wrote:
>> > Hi,
>> >
>> >> Just a wild thought:
>> >> It works with a lower speed line (at least I read it that way) but has
>> >> problems with higher speeds.
>> >> Could it be that the line is so fast that it "overtakes" the host in
>> >> question?
>> >>
>> >> A faster incoming line will give less time between the packets for
>> >> processing.
>> >
>> > No, I actually upgraded from a 65/20mbit to a 165/35mbit recently,
>> > thinking it was too slow because it was happening at the slower speeds
>> > as well. I've also implemented some basic QoS to throttle outgoing
>> > smtp and prioritize DNS but it made no difference.
>> Has your provider enabled qos?  I'd bet their dropping packets that
>> exceed qos rate limits would be considered "working as expected".
> I asked and they had no idea what that even meant.

Escalate?  Which is assuming you have a ticket open..

I had it a bit easier than you; I was in an enterprise environment &
had control of the routers on both sides + it was relatively easy to
demonstrate packet loss.

> The technician that
> was here replacing the modem also had no idea outside of what the
> hardware does.
> I've also asked on dslreports about this, and no one answered.
> It certainly seems to be more pronounced now than it ever was in the
> past. Sometimes so many queries are failing that it's impossible to
> use the network.

Can you make it happen on demand?  Troubleshooting is so much easier
if you can demonstrate the problem vs. trying to reconstruct what
happened after the fact.

>> Which brings up the question of exactly what does SERVFAIL mean?  Can
>> no response to a query result in SERVFAIL?  Is there a way to tell the
>> difference between no response & getting a response indicating a
>> failure?
> Early in this thread or another, I provided a packet trace that showed
> what appears to me to never have received the replies - it just times
> out. Also, the "Server Failure" messages are always on the loopback
> interface. I'd be happy to provide another trace if someone knows how
> to properly read it. I really have no idea what's causing the problem.

It would be nice if there was a way to tell if the problem was packet
drops (ie. no response to a query), getting a bad response from the
server or something else.  At least then you'd know where to direct
your attention..

> Also, I recently raised the trace level to 99, but I don't see
> anything in the logs beyond level 4. Where do I find what the
> different trace levels are supposed to report?

No idea.  I'm running bind at home and very occasionally see things like
28-Sep-2018 1:04:32.552 query-errors: info: client @000001F0C86745C0 ( query failed (SERVFAIL) for at ..\query.c:8580

so I'd be interested in knowing if you get a resolution to the problem.


More information about the bind-users mailing list