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.thurs...@alaska.gov
<mailto:john.thurs...@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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
