Bind can not resolve.
kcd at daimlerchrysler.com
Thu Mar 29 03:12:32 UTC 2007
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
>>>>> CNAME is returned pointing to a parent domain without the corresponding
>>>>> 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.
More information about the bind-users