Strange behaviour resolving CNAME's via a forwarder.

[Ben Croswell]

I believe your original issue is due to the fact that you are sending a
recursive query via the forward to a device you said won't do recursive
queries.  The cname you are asking for is not in the domain hosted by the
second server. Since it won't do recursive queries it won't resolve the end
point of the cname chain.
If you specifically ask for cname first, it caches the cname and then
further queries don't go  to the second box and your first box just resolves
the end of the chain.

-Ben Croswell
On Apr 20, 2011 7:23 AM, "Adam Goodall" <adam.goodall at gmail.com> wrote:
> On 20 April 2011 10:42, Chris Buxton <chris.p.buxton at gmail.com> wrote:
>
>> On Apr 20, 2011, at 2:19 AM, Adam Goodall wrote:
>>
>> However if a client queries server A for mail.testdomain.com (type any)
>> the request is not answered. From the logs on server B i can see that
server
>> A is only forwarding on a request of type A. As an A record for
>> mail.testdomain.com does not exist on server B it does not resolve.
>>
>> If i then specifically query Server A for mail.testdomain.com of type
>> CNAME, it resolves as expected. Subsequent requests against server A for
>> mail.testdomain.com of type any then resolve, presumably because it is
>> already in the cache.
>>
>> Hopefully that makes sense! Has anyone had a similar issue and did you
come
>> up with a work around? Is this expected behaviour or a bug?
>>
>>
>> This is an excellent example of why you should not forward to an
auth-only
>> server. Use a stub zone instead. You might need to give it an empty
>> forwarders list, to override forwarding set in either the options or view
>> statements.
>>
>> For example:
>>
>> zone "testdomain.com" {
>> type stub;
>> masters { 192.168.1.1; };
>> forwarders { };
>> };
>>
>> Try it, you'll like it.
>>
>
> Chris
>
> This certainly seems to have solved the problem. I'm not convinced i
> understand why it didn't work they way i was trying but this is a
perfectly
> acceptable alternative - thanks for your help!
>
> Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110420/ad4ff209/attachment.html>