> 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.
