SERVFAIL

bsfinkel at anl.gov bsfinkel at anl.gov
Thu Sep 11 14:12:44 UTC 2008


Chris Buxton <cbuxton at menandmice.com> wrote in reply:

>In fact, a BIND 9.4.x resolver on my laptop is able to look up www.flickr.com/IN/A 
>  just fine. I don't have 9.5 installed to test with, but unless it's  
>doing something different in the resolver algorithm, I would guess  
>this is a configuration, resource, or network/routing/firewall issue  
>for Barry.


I am not including the entire thread, as it is long.  I have not read
this thread in detail (especially the dialog between Paul Vixie and
Chris Buxton) because it will take me some time to analyze what is
being said about the RFCs.  With BIND 9.5.0-P1 the query

     dig www.flickr.com

sometimes succeeded and sometimes produced SERVFAIL.  I know it
sometimes succeeded because some of my queries returned non-AA info
from the DNS cache.  With the 5- and 15-minute TTLs on the "CNAME" and
"A" records, the cache was cleared relatively quickly.  When I had
installed 9.5.0-P2 with Jinmei's "rndc dumpdb" patch on three of my
four nameservers, I could not get SERVFAIL on the three running -P2,
but I did get SERVFAIL on the one still running -P1.  So, I quickly
updated that fourth server.  I ran few queries after that point, as
the query seemed to be working.  I just ran queries on my two internal
servers, and I got the answers I expected (one answer from the cache
and one with full TTLs).

I have not looked at the code.  Is there anything in the -P2 code
that would explain why the -P2 queries do not fail, based on the
analysis of Paul Vixie?  Does -P2 do anything different in deciding
which ADDITIONAL information to trust and cache?  Thanks.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory          Phone:    +1 (630) 252-7277
9700 South Cass Avenue               Facsimile:+1 (630) 252-4601
Building 222, Room D209              Internet: BSFinkel at anl.gov
Argonne, IL   60439-4828             IBMMAIL:  I1004994


More information about the bind-users mailing list