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. 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. > 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. 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? 27-Sep-2018 16:57:29.688 query-errors: info: client @0x7fc7b0169ac0 127.0.0.1#31675 (72.212.15.199.backscatter.spameatingmonkey.net): query failed (SERVFAIL) for 72.212.15.199.backscatter.spameatingmonkey.net/IN/A at ../../../bin/named/query.c:8580 26-Sep-2018 15:16:32.507 query-errors: debug 2: fetch completed at ../../../lib/dns/resolver.c:3927 for b74c2d3722fbce8841edc1808ea0a31e.ix.dnsbl.manitu.net/A in 30.000092: timed out/success [domain:manitu.net,referral:0,restart:5,qrysent:17,timeout:16,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] There are also tons of messages involving disabling EDNS: 27-Sep-2018 16:57:29.549 edns-disabled: debug 1: success resolving '232.123.75.208.dnsbl-3.uceprotect.net/A' (in 'dnsbl-3.uceprotect.net'?) after disabling EDNS I've also just installed 'netdata', which is an app that reports on system parameters, and find it frequently reporting messages like: ipv4 tcp listen overflows = 4 overflows inbound packets dropped = 22 packets ipv4 udp receive buffer errors = 184 errors I've also now made the following buffer adjustments based on this and other perf tuning docs: https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf net.core.rmem_default = 8388608 net.core.rmem_max = 33554432 net.core.wmem_default = 52428800 net.core.wmem_max = 134217728 net.ipv4.udp_early_demux = 0 net.ipv4.udp_mem=764304 1019072 1528608 net.ipv4.tcp_rmem=16384 349520 16777216 net.core.rmem_max=16777216 net.ipv4.udp_rmem_min = 18192 net.ipv4.udp_wmem_min = 8192 net.core.netdev_budget = 10000 net.core.netdev_max_backlog = 2000 net.core.netdev_max_backlog=100000 Thanks, Alex _______________________________________________ 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