why this query cause ServFail

Sat Sep 10 18:35:19 UTC 2016

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
<nelsonhillary8 at 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 <johnmill at 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 <nelsonhillary8 at 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
>> > <nelsonhillary8 at 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 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
John Miller
Systems Engineer
Brandeis University
johnmill at brandeis.edu
(781) 736-4619