Send bind-users mailing list submissions to bind-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/bind-users or, via email, send a message with subject or body 'help' to bind-users-requ...@lists.isc.org You can reach the person managing the list at bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Fwd: why this query cause ServFail (Hillary Nelson) 2. Re: why this query cause ServFail (John Miller) 3. Re: why this query cause ServFail (Hillary Nelson) ---------------------------------------------------------------------- Message: 1 Date: Sat, 10 Sep 2016 13:39:45 -0400 From: Hillary Nelson <nelsonhilla...@gmail.com> To: bind-users@lists.isc.org Subject: Fwd: why this query cause ServFail Message-ID: <cajs9+ybp7mrp8pp+ptr7ottr34el879_p6rx79cvqcbcsyx...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Thanks John, I've changed the resolver-query-timeout from default 10 to 30 seconds thought my nameserver should have enough time to query at least one other nameservers of production.tacc.utexas.edu before gets timed out. But still it stuck with the one that's not working instead of trying other nameservers. This is the tcpdump as you can see my nameserver 192.168.1.100 keeps querying 129.114.13.17 four times within the 30 seconds, shouldn't it try the one of the other nameservers ? 22:24:32.594680 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A? web1.production.tacc.utexas.edu. (60) 22:24:32.595029 IP 192.168.1.100.65437 > 129.114.13.17.53: 27989% [1au] A? web1.production.tacc.utexas.edu. (60) 22:24:37.594642 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A? web1.production.tacc.utexas.edu. (60) 22:24:41.595312 IP 192.168.1.100.19764 > 129.114.13.17.53: 8074% [1au] A? web1.production.tacc.utexas.edu. (60) 22:24:42.594873 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A? web1.production.tacc.utexas.edu. (60) 22:24:50.595523 IP 192.168.1.100.62364 > 129.114.13.17.53: 18009 A? web1.production.tacc.utexas.edu. (49) 22:24:59.595825 IP 192.168.1.100.58124 > 129.114.13.17.53: 57314 A? web1.production.tacc.utexas.edu. (49) 22:25:02.595236 IP 192.168.1.100.53 > 10.79.1.6.42064: 25767 ServFail 0/0/1 (60) I'll contact the admin for the domain to gets the broken nameserver fixed, but seems to me there is also problem with how named handle the NS of this domain, or there is other parameter to tell named to try to loop through other nameservers if one fails. On Fri, Sep 9, 2016 at 7:20 PM, John Miller <johnm...@brandeis.edu> wrote: > Hi Hillary, > > By default, BIND will return SERVFAIL to the client if it can't > complete the full iteration process within 10 seconds. This is > controllable by the "resolver-query-timeout" parameter. As for why > your recursive server doesn't just try elsewhere, it _will_, but it > assumes that it's querying a valid nameserver, so the original query > needs to time out first. It takes several queries for BIND to get its > round-trip time cache in order. With six authoritative NSs, it'll > take longer than if you only had three. > > As for 129.114.13.18 being lame - it's hard to be lame if you aren't > getting responses. Lame just means that responses from the nameserver > aren't authoritative, even though it's listed in your NS records. > > Your best option is to fix the non-responding nameservers or remove > them from your NS records if they aren't supposed to respond to > queries - name resolution isn't just broken for you, it's broken for > everyone who wants to find web1.production.tacc.utexas.edu. > > John > > On Fri, Sep 9, 2016 at 5:23 PM, Hillary Nelson <nelsonhilla...@gmail.com> > wrote: > > Also should mention that our BIND is 9.9.8-P4, what confuses me here is > that > > the listed nameserver (129.114.13.18) is lame and our nameserver ( > > 192.168.1.100) can't get any responses from it(see tcpdump above), why > our > > nameserver try other listed NS servers instead sending 'ServFail' to the > > client(10.79.1.6) ? > > Any help will be greatly appreciated! > > > > On Fri, Sep 9, 2016 at 1:07 PM, Hillary Nelson <nelsonhilla...@gmail.com > > > > wrote: > >> > >> We've been seeing sporadic failure of resolve this name > >> web1.production.tacc.utexas.edu from our nameserver. > >> > >> There are 6 NS listed for domain production.tacc.utexas.edu, two of the > >> six don't seem to work(dc1.production.tacc.utexas.edu 129.114.13.17 and > >> dc2.production.tacc.utexas.edu 129.114.13.18). > >> > >> If our nameserver hits the two and doesn't get any response, it sends > >> 'ServFail' to client, shouldn't the our nameserver keeps trying the > other > >> four working nameservers listed for the domain ? > >> > >> Here is the tcpdump: > >> > >> 12:33:38.593146 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A? > >> tas.tacc.utexas.edu. (48) > >> 12:33:38.593573 IP 192.168.1.100.54985 > 129.114.13.18.53: 40455% [1au] > A? > >> web1.production.tacc.utexas.edu. (60) > >> 12:33:43.593131 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A? > >> tas.tacc.utexas.edu. (48) > >> 12:33:47.593796 IP 192.168.1.100.49009 > 129.114.13.18.53: 38559% [1au] > A? > >> web1.production.tacc.utexas.edu. (60) > >> 12:33:48.593234 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A? > >> tas.tacc.utexas.edu. (48) > >> 12:33:48.593583 IP 192.168.1.100.53 > 10.79.1.6.51980: 60950 ServFail > >> 0/0/1 (48) > >> > >> > >> Thanks in advance for your help! > >> > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160910/19577710/attachment-0001.html> ------------------------------ Message: 2 Date: Sat, 10 Sep 2016 14:35:19 -0400 From: John Miller <johnm...@brandeis.edu> Cc: Bind Users Mailing List <bind-users@lists.isc.org> Subject: Re: why this query cause ServFail Message-ID: <CAGYMsbvqJ__oCbh=o6s7ewvVrM_tsCMR7hNrQUCgsLKZ=p-...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hillary, I suspect there's more going on behind the scenes than just what your tcpdump shows here. Can you please post your named.conf file so we can all see if there are any forwarders, stub zones, etc. involved here? Second thing: after you flush your cache, does the same behavior persist, or does BIND try a different nameserver? Finally, can you post the tcpdump command you're using? John On Sat, Sep 10, 2016 at 1:39 PM, Hillary Nelson <nelsonhilla...@gmail.com> wrote: > Thanks John, I've changed the resolver-query-timeout from default 10 to 30 > seconds thought my nameserver should have enough time to query at least one > other nameservers of production.tacc.utexas.edu before gets timed out. But > still it stuck with the one that's not working instead of trying other > nameservers. This is the tcpdump as you can see my nameserver 192.168.1.100 > keeps querying 129.114.13.17 four times within the 30 seconds, shouldn't it > try the one of the other nameservers ? > > 22:24:32.594680 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A? > web1.production.tacc.utexas.edu. (60) > 22:24:32.595029 IP 192.168.1.100.65437 > 129.114.13.17.53: 27989% [1au] A? > web1.production.tacc.utexas.edu. (60) > 22:24:37.594642 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A? > web1.production.tacc.utexas.edu. (60) > 22:24:41.595312 IP 192.168.1.100.19764 > 129.114.13.17.53: 8074% [1au] A? > web1.production.tacc.utexas.edu. (60) > 22:24:42.594873 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A? > web1.production.tacc.utexas.edu. (60) > 22:24:50.595523 IP 192.168.1.100.62364 > 129.114.13.17.53: 18009 A? > web1.production.tacc.utexas.edu. (49) > 22:24:59.595825 IP 192.168.1.100.58124 > 129.114.13.17.53: 57314 A? > web1.production.tacc.utexas.edu. (49) > 22:25:02.595236 IP 192.168.1.100.53 > 10.79.1.6.42064: 25767 ServFail 0/0/1 > (60) > > I'll contact the admin for the domain to gets the broken nameserver fixed, > but seems to me there is also problem with how named handle the NS of this > domain, or there is other parameter to tell named to try to loop through > other nameservers if one fails. > > > > On Fri, Sep 9, 2016 at 7:20 PM, John Miller <johnm...@brandeis.edu> wrote: >> >> Hi Hillary, >> >> By default, BIND will return SERVFAIL to the client if it can't >> complete the full iteration process within 10 seconds. This is >> controllable by the "resolver-query-timeout" parameter. As for why >> your recursive server doesn't just try elsewhere, it _will_, but it >> assumes that it's querying a valid nameserver, so the original query >> needs to time out first. It takes several queries for BIND to get its >> round-trip time cache in order. With six authoritative NSs, it'll >> take longer than if you only had three. >> >> As for 129.114.13.18 being lame - it's hard to be lame if you aren't >> getting responses. Lame just means that responses from the nameserver >> aren't authoritative, even though it's listed in your NS records. >> >> Your best option is to fix the non-responding nameservers or remove >> them from your NS records if they aren't supposed to respond to >> queries - name resolution isn't just broken for you, it's broken for >> everyone who wants to find web1.production.tacc.utexas.edu. >> >> John >> >> On Fri, Sep 9, 2016 at 5:23 PM, Hillary Nelson <nelsonhilla...@gmail.com> >> wrote: >> > Also should mention that our BIND is 9.9.8-P4, what confuses me here is >> > that >> > the listed nameserver (129.114.13.18) is lame and our nameserver ( >> > 192.168.1.100) can't get any responses from it(see tcpdump above), why >> > our >> > nameserver try other listed NS servers instead sending 'ServFail' to >> > the >> > client(10.79.1.6) ? >> > Any help will be greatly appreciated! >> > >> > On Fri, Sep 9, 2016 at 1:07 PM, Hillary Nelson >> > <nelsonhilla...@gmail.com> >> > wrote: >> >> >> >> We've been seeing sporadic failure of resolve this name >> >> web1.production.tacc.utexas.edu from our nameserver. >> >> >> >> There are 6 NS listed for domain production.tacc.utexas.edu, two of the >> >> six don't seem to work(dc1.production.tacc.utexas.edu 129.114.13.17 and >> >> dc2.production.tacc.utexas.edu 129.114.13.18). >> >> >> >> If our nameserver hits the two and doesn't get any response, it sends >> >> 'ServFail' to client, shouldn't the our nameserver keeps trying the >> >> other >> >> four working nameservers listed for the domain ? >> >> >> >> Here is the tcpdump: >> >> >> >> 12:33:38.593146 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A? >> >> tas.tacc.utexas.edu. (48) >> >> 12:33:38.593573 IP 192.168.1.100.54985 > 129.114.13.18.53: 40455% [1au] >> >> A? >> >> web1.production.tacc.utexas.edu. (60) >> >> 12:33:43.593131 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A? >> >> tas.tacc.utexas.edu. (48) >> >> 12:33:47.593796 IP 192.168.1.100.49009 > 129.114.13.18.53: 38559% [1au] >> >> A? >> >> web1.production.tacc.utexas.edu. (60) >> >> 12:33:48.593234 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A? >> >> tas.tacc.utexas.edu. (48) >> >> 12:33:48.593583 IP 192.168.1.100.53 > 10.79.1.6.51980: 60950 ServFail >> >> 0/0/1 (48) >> >> >> >> >> >> Thanks in advance for your help! >> >> >> _______________________________________________ >> 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 -- John Miller Systems Engineer Brandeis University johnm...@brandeis.edu (781) 736-4619 ------------------------------ Message: 3 Date: Sat, 10 Sep 2016 18:03:33 -0400 From: Hillary Nelson <nelsonhilla...@gmail.com> To: bind-users@lists.isc.org Subject: Re: why this query cause ServFail Message-ID: <CAJS9+YaiYiYaWJYnexrmykFtBbd2gk-52LSF4Va+9=nalxe...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" I've double checked our nameserver config and there shouldn't be any stub involved when resolving this domain, we don't have forwarder configured. After flush the cache or the cache expires itself(the ttl is short), bind almost always hit another server and works, we have 9 named resolvers, anytime I checked there are always one or two(not the same ones) has problem with this domain. The nameserver is dedicated and on RHEL 6.8, tcpdump command: tcpdump -i any -nn port 53 Here is named.conf, please let me know if there is anythings else needed: include "/etc/rndc.key"; include "/named/acl"; controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { localkey; }; }; options { listen-on-v6 { any; }; listen-on { any; }; directory "/named"; dump-file "/var/run/named_dump.db"; pid-file "/var/run/named.pid"; recursing-file "/var/run/named.recursing"; statistics-file "/var/run/named.stats"; transfer-format many-answers; max-transfer-time-in 60; resolver-query-timeout 30; check-names master ignore; check-names slave ignore; check-names response ignore; datasize default; stacksize default; coresize default; files unlimited; recursion yes; notify no; auth-nxdomain no; version "unknown"; response-policy { zone "dns-policy.rpz.zone"; }; allow-transfer { xfer; }; allow-query { all-allowed; }; allow-query-cache { all-allowed; }; allow-recursion { all-allowed; }; blackhole { bogon; }; include "validate"; include "anycast.server"; }; server fe80::/16 { bogus yes; }; server ::/0 { bogus yes; }; include "logging.conf"; include "trusted-keys.conf"; include "gen.conf"; include "rpz.conf"; include "Secondary.conf"; Thanks!! -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160910/6773888a/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ------------------------------ End of bind-users Digest, Vol 2489, Issue 2 ******************************************* If you wish to unsubscribe from receiving commercial electronic messages from TD Bank Group, please click here or go to the following web address: www.td.com/tdoptout Si vous souhaitez vous désabonner des messages électroniques de nature commerciale envoyés par Groupe Banque TD veuillez cliquer ici ou vous rendre à l'adresse www.td.com/tddesab NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. If received in error, please go to www.td.com/legal for instructions. AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. Si reçu par erreur, prière d'aller au www.td.com/francais/avis_juridique pour des instructions. _______________________________________________ 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