Re: why this query cause ServFail

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

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

Fwd: why this query cause ServFail

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 na

Re: why this query cause ServFail

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

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

why this query cause ServFail

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)