Behavior of 'forward only' zone

[Petr Špaček]

Hi John.

Let me add that NOT restricting what the resolver accepts from the 
forwarder would be a security hole. In fact is _was_ a security hole in 
BIND, see
[CVE-2021-25220] DNS Cache Poisoning Vulnerability
https://gitlab.isc.org/isc-projects/bind9/-/issues/2950

In your example 'baz.local' subtree also needs to be configured as a 
forwarder.

HTH.

Petr Špaček
Internet Systems Consortium



On 21. 08. 24 0:05, Greg Choules via bind-users wrote:
> Hi John.
> The reason is step 4c here: 
> https://datatracker.ietf.org/doc/html/rfc1034#section-5.3.3 
> <https://datatracker.ietf.org/doc/html/rfc1034#section-5.3.3>
> 
> The A record in the response is for a name that BIND wasn't asked for 
> (otherwise why a CNAME at all?), so in the interests of not just 
> believing random answers that might potentially poison the cache, BIND 
> needs to check for itself, even if the resulting fetch is sent to the 
> same forwarder.
> 
> Your resolver somehow needs to be able to get an answer to the target of 
> the CNAME. Not knowing your setup I can't say *how* it could do this. 
> But possibly by forwarding that name, or a (grand)parent of that domain 
> to another resolver that can get the answer for it?
> 
> Hope that helps.
> Cheers, Greg
> 
> On Tue, 20 Aug 2024 at 21:28, John Thurston <john.thurston at alaska.gov 
> <mailto:john.thurston at alaska.gov>> wrote:
> 
>     __
> 
>     We are asked to forward queries for foo.example.com
>     <http://foo.example.com> to a set of private resolvers. So we have
>     something like this in our .conf
> 
>>     zone "foo.example.com <http://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
>     <http://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
>     <http://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?

-- 
Petr Špaček