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