On 9/28/18, Alex <mysqlstud...@gmail.com> wrote: > Hi, > > On Fri, Sep 28, 2018 at 12:18 AM Lee <ler...@gmail.com> wrote: >> >> On 9/27/18, Alex <mysqlstud...@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 >> 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 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. Lee _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
