Behavior of 'forward only' zone

[John Thurston]

We are asked to forward queries for foo.example.com to a set of private 
resolvers. So we have something like this in our .conf

> zone "foo.example.com" {type forward; forward only;
>         forwarders { 10.1.2.3; 10.1.4.5; };
> };

And when queried for an A-record for bar.foo.example.com (and the 
A-record exists), the query is forwarded, the answer is received, 
cached, and returned to the customer.

But in the case where bar.foo.example.com is an alias to a record in 
some other domain (e.g. foo.baz.local), the behavior is different.

With a packet capture, I can see the query being forwarded to one of the 
targets (with the 'recursion desired' bit set). I can see the reply 
coming back with the 'recursion available' bit set, and the answer 
containing the CNAME, and the ultimate A-record. The distant server has 
performed the requested recursion.

My recursive server does not, however, return the final A-record to the 
customer. It attempts to resolve the intermediate CNAME, and (since the 
CNAME is to another private domain of which I have no knowledge) it 
fails. An NXDOMAIN is returned to the customer.

I understood the 'type forward' to be a 'hand off'. My server would set 
the rd-bit, forward the query on, and accept (and return) whatever 
answer was received. If I'm correctly interpreting what I see, my server 
will accept whatever answer is received but only for exactly the zone 
named in zone-statement. When the answer contains an alias to some other 
domain, my server hands that name back into its own recursing process.

Is there some way to configure BIND so it will simply pass back to the 
customer whatever answer is received from the distant resolver?


-- 
--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240820/1f3004a8/attachment.htm>