SERVFAIL
Chris Buxton
cbuxton at menandmice.com
Thu Sep 11 00:38:21 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 10, 2008, at 4:26 PM, Paul Vixie wrote:
>> 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 thought I had. It appeared to me you had made a mistake. Perhaps I
read it wrong; I'm willing to be corrected. However, I have had
occasion to correct your thinking once before...
> 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
an NXRRSet (aka no data) response
> and sometimes that there is a zone
> cut between the zone whose server you queried and the zone that
> contains
> your data,
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.
Can you point to a name server version that gives a pure referral with
the aa flag set?
> 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)
Again, I thought aa was supposed to be reserved for (final) answers.
Now granted I've seen the aa flag on answers from resolvers when the
answer did not come from cache, but that's a different issue. If you
send an iterative query and the response has aa set, it should be both
authoritative and an answer (not a referral).
> 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.
> 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).
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.
> 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.
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.
> 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.
Hmm...
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...). If we do, then if a broken name
server sets aa for a referral, we have a problem. However, the damage
is limited to the zones served by that server and the descendants of
those zones.
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.
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.
> 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.
Exactly. The responding server simply sends the best answer it can
make from available data.
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.
Chris Buxton
Professional Services
Men & Mice
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkjIaH0ACgkQ0p/8Jp6Boi2KMgCfVJQnjaOF2bim6VnceggslBIq
J5gAn0cOTSvPwaEKKtGIncxMIo1q3pIT
=RRty
-----END PGP SIGNATURE-----
More information about the bind-users
mailing list