> From: Chris Buxton <[EMAIL PROTECTED]> > > A name server may be authoritative for both a zone and its subzone. Your > traversal tool is wrong - the server is giving an authoritative answer, > not a downward referral. Your tool should consider an authoritative > answer as trumping the authority section, if there is any conflict.
chris, i'm not sure you read my earlier statement. i will try again, differently. there are many ambiguities in the dns protocol specification and this is one of them. the meaning of (AA && ANCOUNT==0) is sometimes that there are no records of type=QTYPE and sometimes that there is a zone cut between the zone whose server you queried and the zone that contains your data, and to disambiguate you have to look at the authority section to see if there are some NS RRs whose owner names are below the zone whose server you were querying (in which case you know (AA && ANCOUNT==0) means it's a delegation) or at the zone you were querying (in which case (AA && ANCOUNT==0) means that there are no records of type==QTYPE). in preparing my traversal tool many things dawned on me since i did it from memory 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). one of the dawnings was that (AA && ANCOUNT>0) actually presents the same ambiguity, since many servers will provide an answer if QTYPE=NS even though we all know from the years spent on DNSSEC that NS RRs are only authoritative in the child zone. therefore my traversal tool looks first to see if there is a delegation (which means a non-empty authority section containing NS RRs whose owners are below the zone whose servers i'm querying, also called "the bailiwick", and if these are present, then the delegation is followed, and the answer, whether empty or not, is ignored. this is not the only possible way to interpret the ambiguities of RFC 1034 and RFC 1035, but i like it since it helps work around various misconfigurations which have in the past caused me to cache bad data. now, the server isn't doing the wrong thing, but the server operator had better be prepared to accept the same query a second time. the real problem, if there is a problem, is that a server for both a zone and its child, has no way to know what bailiwick the resolver has iterated down to. there is no fix for the server absent this important information. > It is common for an authoritative answer to contain the NS records of the > zone containing the answer, along with any known addresses for those > servers. thanks for explaining that.
