Bind can not resolve.

[Kevin Darcy]

Barry Margolin wrote:
> In article <euf6oj$e9l$1 at sf1.isc.org>,
>  Mark Andrews <Mark_Andrews at isc.org> wrote:
>
>   
>>> In article <eud6c6$25r1$1 at sf1.isc.org>,
>>>  Mark Andrews <Mark_Andrews at isc.org> 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.
>>>>         
>>> While this would certainly make resolution faster, I can't see why 
>>> failing to follow the CNAME should cause the resolver to fail.  If the 
>>> authoritative server doesn't follow the CNAME automatically, the 
>>> resolver should do so, just as it must if the CNAME pointed to a zone 
>>> that's hosted on a different server from the CNAME itself.
>>>       
>> 	By not following the algorithm through to conclusion they
>> 	generated a bad referral.
>>     
>
> What referral?  It looks to me like it's the NS record of the zone 
> containing the record being returned.  
Right. Anytime you *dont* return an answer, but rather an NS RRset in 
the Authority Section that is intended to point the resolver closer to 
the answer, that's a "referral". CNAME-chasing can cause referrals to be 
"sideways" rather than "down".
> It's normal behavior to include 
> this record in the authority section of a response.
>   
It's normal behavior to include an NS RRset in the Authority Section, 
for the RRset that answers the question, or, in the case of a referral, 
which points closer to the answer. If you do a non-recursive query from 
our nameservers for www.chrysler.com (running BIND 9), for instance, the 
Authority Section of the response will contain ".net" NS records, rather 
than chrysler.com NS records, since the canonical name pointed to by the 
www.chrysler.com CNAME is in the .net TLD. That's the way such a 
referral response *should* look.

Getting back to the cname.bind9.expol.us response, however, there is, at 
that point in the resolution process, a working assumption that an A 
RRset owned by the name foo.expol.us is the answer. But the NS record in 
the response is for the bind9.expol.us zone, which doesn't get the 
resolver any closer to resolving foo.expol.us. Hence, it is a referral, 
but a bad one.

>> 	"foo.expol.us" is not a (sub)domain of "bind9.expol.us".
>>
>> 	Named rejects this.  Yes we are picky however we have been
>> 	burnt too many times by not being picky enough.
>>     
>
>   
>> 	Note the response below would be fine if the QTYPE was
>> 	CNAME or * as the CNAME is not supposed to be followed
>> 	in those cases.
>>     
>
> What if the CNAME pointed to a totally unrelated zone that wasn't in the 
> authoritative server's cache?  Wouldn't you expect it to return an 
> answer just like the one below?
>   
It should either answer with NS records that are the "best" that it can 
come up with for the restarted QNAME, or none at all. Putting root NS 
records in the Authority Section would be valid and acceptable. Putting 
NS records in the Authority Section which are in a different delegation 
hierarchy, however, is pointless and has the potential to lead 
poorly-implemented resolvers astray. The only question is whether BIND 
is a little draconian in actually *rejecting* a response like this. It 
could, after all, just ignore what's in the Authority Section, restart 
the query with the canonical name, and resolve it to an answer. That's a 
design choice, and Mark already gave the rationale behind it.

                                                                         
                                 - Kevin