Bind can not resolve.

[Kevin Darcy]

Pawel Rogocz wrote:
> On Wed, Mar 28, 2007 at 05:37:44PM +1000, Mark Andrews wrote:
>   
>>> bind9 seem to be unable to resolve if during resolution of an A record a
>>> CNAME is returned pointing to a parent domain without the corresponding A
>>> record.
>>>
>>> Example: cname.bind9.expol.us
>>>
>>> Trying CNAME first makes A resolution work, otherwise I get SERVFAIL.
>>>       
>> 	It would help if the authorative servers actually followed
>> 	RFC 1034.  The server should be including the A record in
>> 	the answer as it serves the parent zone.  If should also be
>> 	returning a referral to the parent zone (not the child zone)
>> 	if it returns the implicit referral.
>>     
>
> Could you point me to the sections of RFC 1034 which back up your two
> points ? I was only able to find recipes for recursive nameservers:
>
> 5.3.3
>          c. if the response shows a CNAME and that is not the
>             answer itself, cache the CNAME, change the SNAME to the
>             canonical name in the CNAME RR and go to step 1.
>
> In case of cname.bind9.expol.us bind9 for some reason does not restart
> the query and we have a problem. 
>   
Mark was referring to the parts of RFC 1034 which apply to 
*authoritative* nameservers.

Section 4.3.2.

   3. Start matching down, label by label, in the zone.  The
      matching process can terminate several ways:

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

When the query is restarted at step 1 with the canonical name 
foo.expol.us, since the nameserver serves the parent zone it should go 
all of the way back through this algorithm to the "Otherwise" sentence 
of 3a and provide the foo.expol.us A record in the Answer Section. 
Obviously it's not doing that.

As for Mark's comment about referral, I think he means that _if_ the 
authoritative nameservers are going to disobey RFC 1034 by not actually 
resolving the A record, presumably because, in the context of that 
query, they don't recognize the parent zone as one for which they are 
authoritative, then _at_the_very_least they should fall through to step 
4 of the algorithm:

4. Start matching down in the cache.  If QNAME is found in the
      cache, copy all RRs attached to it that match QTYPE into the
      answer section.  If there was no delegation from
      authoritative data, look for the best one from the cache, and
      put it in the authority section.

Clearly the bind9.expol.us NS record is not the *best* available, since 
it's neither identical to, nor an ancestor of the (restarted) QNAME 
foo.expol.us. No DNS responder should ever give referral information 
that's outside of the delegation hierarchy for the name that it's 
directly or (in the case of CNAMEs) indirectly answering for. At best, 
it's extraneous; at worst, it can cause a malfunction of the client's 
resolver algorithm, which might go wandering off into a branch of the 
namespace that can't possibly contain the name it's looking for.

One could argue, I suppose, that if the authoritative nameserver is 
completely blind to the contents of the expol.us zone, Step 4 doesn't 
apply (i.e. none of that data is "cached" either), in which case the 
restarted query would presumably fall all of the way to Step 6, which 
leaves the Authority Section *empty*. Sometimes saying nothing is better 
than giving misleading information...

- Kevin