SERVFAIL

[Paul Vixie]

> From: Chris Buxton <cbuxton at menandmice.com>
> 
> 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.