Re: BIND and UDP tuning
Hi there, On Sun, 30 Sep 2018, Alex wrote: Sep 29 14:33:54 mail03 postfix/dnsblog[3290]: warning: dnsblog_query: lookup error for DNS query 123.139.28.66.dnsbl.sorbs.net: Host or domain name not found. Name service error for name=123.139.28.66.dnsbl.sorbs.net type=A: Host not found, try again I'd really be interested in people's input here. Are your requests being dropped by the service(s)? (Or: are you inadvertently abusing the said service(s)?) -- 73, Ged. ___ 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
Re: BIND DNS problem (?)
On Sep 26, 2018, at 07:52, Jukka Pakkanen wrote: > Still Symantec "enterprise support technician" claims the problem is on our > DNS servers, and as a "proof" send the chapter 4.1.1 of the RFC1035, where it > is stated that "code 2 = server failure", and this should prove that our > servers are not working because they got "server failure" error ;-) Somehow, this coming from someone at Symantec is not at all surprising. -- My main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% now. ___ 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
Re: BIND and UDP tuning
Hi, > > Sep 29 14:33:54 mail03 postfix/dnsblog[3290]: warning: > > dnsblog_query: lookup error for DNS query > > 123.139.28.66.dnsbl.sorbs.net: Host or domain name not found. Name > > service error for name=123.139.28.66.dnsbl.sorbs.net type=A: Host > > not found, try again > > > > I'd really be interested in people's input here. > > Are your requests being dropped by the service(s)? > (Or: are you inadvertently abusing the said service(s)?) I don't believe so - often times a follow-up host query succeeds without issue. It's also failing for invaluement and spamhaus, both of which we subscribe. 30-Sep-2018 11:42:04.345 query-errors: info: client @0x7f7910197080 127.0.0.1#46806 (177.32.208.162.bad.psky.me): query failed (SERVFAIL) for 177.32.208.162.bad.psky.me/IN/A at ../../../bin/named/query.c:8580 30-Sep-2018 11:32:31.245 query-errors: info: client @0x7f7920170d30 127.0.0.1#30816 (86.131.2.198.zz.countries.nerd.dk): query failed (SERVFAIL) for 86.131.2.198.zz.countries.nerd.dk/IN/A at ../../../bin/named/query.c:8580 # host 177.32.208.162.bad.psky.me Host 177.32.208.162.bad.psky.me not found: 3(NXDOMAIN) # host 61.200.226.173.zz.countries.nerd.dk 61.200.226.173.zz.countries.nerd.dk has address 127.0.3.72 It also tends to happen in bulk - there may be 25 SERVFAILs within the same second, then nothing for another few minutes. I believe an early tcpdump trace showed that we were just not receiving the responses, although I don't know if it was due to the service itself (doubtful, particularly for the reasons mentioned above), or something along the way was dropping the packets. This appears to indicate the response was never received: 27-Sep-2018 16:57:06.509 query-errors: info: client @0x7fc7a42f6900 127.0.0.1#46680 (fidelity.com.wild.pccc.com): query failed (SERVFAIL) for fidelity.com.wild.pccc.com/IN/A at ../../../bin/named/query.c:8580 27-Sep-2018 16:57:06.510 query-errors: debug 2: fetch completed at ../../../lib/dns/resolver.c:3927 for fidelity.com.wild.pccc.com/A in 30.000130: timed out/success [domain:wild.pccc.com,referral:0,restart:7,qrysent:7,timeout:6,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] I attempted to search github for query.c line 8580, but there weren't even that many lines in file. Is there any further bind debugging that can be done to determine this? I've tried increasing the tracing level to 99, but it doesn't appear to show any more than trace level 4. ___ 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
Re: BIND and UDP tuning
On 30 Sep 2018, at 09:59, Alex wrote: > It also tends to happen in bulk - there may be 25 SERVFAILs within the > same second, then nothing for another few minutes. That really makes it seem like either you modem or you ISP is interfering somehow, or is simply not able to keep up. -- 'Who's that playing now, Mr. Dibbler?' "'And you".' 'Sorry, Mr. Dibbler?' 'Only they write it &U,' said Dibbler. --Soul Music ___ 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
Re: BIND and UDP tuning
Hi, On Sun, Sep 30, 2018 at 1:19 PM @lbutlr wrote: > > On 30 Sep 2018, at 09:59, Alex wrote: > > It also tends to happen in bulk - there may be 25 SERVFAILs within the > > same second, then nothing for another few minutes. > > That really makes it seem like either you modem or you ISP is interfering > somehow, or is simply not able to keep up. I'm leaning towards that, too. The problem persists even when using the provider's DNS servers. I thought for sure I'd see some verifiable info from other people having problems with cable, such as from dslreports, etc, but there really hasn't been anything. The comment made about DOCSIS earlier in this thread was helpful. Do you believe it could be impacting all data, not just bind/DNS/UDP? Do people not generally use cable as even a fallback link for secondary services? I figured it was because there's no SLA, not because it doesn't work well with many protocols. I'd imagine services like Netflix and youtube don't have problems is because they 1) don't require a lot of DNS traffic and 2) http is a really simple protocol and 3) the link is probably engineered to be used for that? > > > -- > 'Who's that playing now, Mr. Dibbler?' "'And you".' 'Sorry, Mr. > Dibbler?' 'Only they write it &U,' said Dibbler. --Soul Music > > ___ > 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 ___ 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
RE: BIND and UDP tuning
> -Original Message- > From: bind-users On Behalf Of Alex > I'm leaning towards that, too. The problem persists even when using > the provider's DNS servers. I thought for sure I'd see some verifiable > info from other people having problems with cable, such as from > dslreports, etc, but there really hasn't been anything. The comment > made about DOCSIS earlier in this thread was helpful. > > Do you believe it could be impacting all data, not just bind/DNS/UDP? > > Do people not generally use cable as even a fallback link for > secondary services? I figured it was because there's no SLA, not > because it doesn't work well with many protocols. I'd imagine services > like Netflix and youtube don't have problems is because they 1) don't > require a lot of DNS traffic and 2) http is a really simple protocol > and 3) the link is probably engineered to be used for that? I use sendmail and bind at home for my purposes, and don't have these sorts of issues. But what probably solves this for most users is the fact that most home-sort-of-users use TCP rather than UDP. UDP is designed as a lossy protocol; no resends, no guaranteed delivery at a protocol level. If you're really concerned with the occasional SERVFAIL due to this (which your stub resolver should be retrying), you could try convincing BIND to recurse using TCP only. It's not a good idea (and I'm pretty sure doesn't have the option to do it natively)... Stuart ___ 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
