SERVFAIL

Paul Vixie vixie at vix.com
Thu Sep 11 01:40:04 UTC 2008


> Really? I've never seen a referral marked with the aa flag. (But you  
> obviously have more years of experience than I.) I thought it was  
> pretty clear in the RFC that a referral does not constitute an  
> authoritative answer - it's neither authoritative nor an answer.

load balancers do funny things.

> Can you point to a name server version that gives a pure referral with  
> the aa flag set?

not offhand.  i ran into them when coding my tool, and coded around them.

> Again, I thought aa was supposed to be reserved for (final) answers.  

it is.  supposed to be, that is.

> > or at the zone you were querying (in which case (AA &&
> > ANCOUNT==0) means that there are no records of type==QTYPE).
> 
> Right, the NXRRSet response.

i wish you'd stop calling it that.  i added the nxrrset rcode in RFC 2136
but it is only applicable to updates.  if you mean ANCOUNT==0, say so.

> > ... and without reference to any RFC (except RFC 2671 which i had to
> > refer to and which i found to be badly written in the extreme).
> 
> I'll defer to the opinion of the author, but I've seen worse. The RFC's
> describing IDNA, ACE, and punycode, for example, are completely opaque to
> me.

RFC 2671 seemed perfectly adequate to me as its author.  it wasn't until
years later than i tried to implement EDNS0 using that document as my
reference that its many shortcomings flowed in neon.

> Can you point to a name server software version that marks delegation NS
> records as authoritative even when specifically asked for them? I would
> call that a protocol violation. I've seen them go in the answer section
> (BIND 8), and I've seen them put in the authority section (BIND 9), but
> I've never seen them marked with aa.

try bind4.8 i think.  or the microsoft NT 3.51 resource kit.  or many load
balancers.  it's only a protocol "violation" if the other guy can't and also
won't work around it.

> If we don't allow below-bailiwick assertions of authority in an  
> authoritative answer, then the resolver has to consider it a  
> delegation and (effectively) re-send the query (which then requires  
> that the NS records be accurate...).

yes.  which works, by the way.

> However, let's suppose that we consider it a delegation and resend the
> query - in this case, the query goes to one of the same servers as the
> parent zone. You had described this as "the hard part of the traversal";
> I don't see how throwing an extra query into the recursion process would
> result in a SERVFAIL response.

i don't know that it is the cause of this servfail, only that it's
suspicious based on the output of my toy resolver in "trace" mode.

> 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 sure that if bind had a problem looking up flickr, it would be on the
front page of every newspaper, etc.  so i agree that this is likely to be
some kind of middlebox issue.  but possibly a data dependent middlebox issue.

> This sounds like you're arguing against including NS records in the  
> authority section of an answer (as opposed to a referral), because it  
> can confuse the resolver. This is the default behavior of at least one  
> non-BIND name server - an authoritative positive answer has just an  
> answer section.

i'm not arguing that the server should do anything differently.  i just think
server operators should be prepared for some extra queries when they do this.


More information about the bind-users mailing list