Re: why this query cause ServFail

2016-09-10 Thread Hillary Nelson
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, anytim

Re: why this query cause ServFail

2016-09-10 Thread John Miller
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

Re: why this query cause ServFail

2016-09-09 Thread John Miller
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 quer

Re: why this query cause ServFail

2016-09-09 Thread Hillary Nelson
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