BIND and UDP tuning
ler762 at gmail.com
Fri Sep 28 14:45:43 UTC 2018
On 9/28/18, Alex <mysqlstudent at gmail.com> wrote:
> On Fri, Sep 28, 2018 at 12:18 AM Lee <ler762 at gmail.com> wrote:
>> On 9/27/18, Alex <mysqlstudent at gmail.com> 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
> 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
> 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
127.0.0.1#63459 (www.Amazon.com): query failed (SERVFAIL) for
www.Amazon.com/IN/A 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