This is a discussion on Re: DNS "chicken-and-egg" Problem - DNS ; At Fri, 31 Oct 2008 14:22:33 -0500 (CDT), email@example.com wrote: > There are a number of problems that arise out of trying to find the > authoritive answer to the question > > What is the "A" record for igpp.ucla.edu? ...
At Fri, 31 Oct 2008 14:22:33 -0500 (CDT),
> There are a number of problems that arise out of trying to find the
> authoritive answer to the question
> What is the "A" record for igpp.ucla.edu?
> 1) Sometimes I get SERVFAIL when I query my local name servers.
> And I am not sure why.
> 2) When I query the four UCLA name servers I get an answer, but that
> answer does not have the "aa" bit set. I am not sure
> a) why the "aa" bit is not set, as the answer is coming from an
> authoritative name server.
As others pointed out, this is the expected (though a bit unusual)
behavior. There's nothing wrong here. You should ask "igpp.ucla.edu"
server (= 184.108.40.206) if you want to manually get an authoritative
> b) why BIND is not cacheing that information. Maybe because the
> information is not marked authoritative? Maybe because the
> DNS cache is being cleaned to aggressively (as JINMEI thinks)?
As I said in my previous response, I believe the right question is why
some of the servers (sometimes?) return SERVFAIL. Cache entries can
be purged for various reasons especially in a busy server, so it's not
always easy to identify the reason, and it may not necessarily be
useful to solve the actual problem.
To debug the SERVFAIL problem, I suggest raising logging level of the
'resolver' category to 'debug 3' while you are seeing the SERVFAILs.
This will produce detailed trace logs of recursive resolution, and
will help identify how the query fails. The log output will be noisy
on a busy server, so you may not want to keep it on after the
We also have an informal (unreleased) patch to provide detailed logs
to identify SERVFAIL causes. If you're willing to test the informal
patch, I'll send it to you.
Internet Systems Consortium, Inc.