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