On 16/05/22 20:05, Angus Clarke wrote:
As mentioned in a separate reply to Grant, the goal is to have
(amongst other things) local recursors "find" the locally deployed
authoritative servers through NS records. What hasn't been mentioned
is that I am also looking to simplify configuration management by
means of a single set of data which can be deployed to all
authoritative servers - I don't think the RPZ solution proposed by
Nick achieves that.
That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can.
Hi Angus.
Thanks for clarifying. Based on what you've said, what I proposed
probably has slightly more merit than I concluded, although admittedly
it doesn't quite tick all the boxes...
Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are
represented as prefixlength.B4.B3.B2.B1.rpz-client-ip. In my examples I
was specifying a single host which is why the RPZ-CLIENT-IP records all
started with 32.
Secondly, RPZs are more commonly used on recursive resolvers rather than
the authoritative nameservers for the zone, although in your case if you
are wanting to change the answer that an authoritative nameserver gives
to the NS question from the recursive resolver, then it probably makes
the most sense to put the RPZ on the authoritative nameserver. In this
case you'd also need to specify "recursive-only no". (FYI Default
behaviour is to apply RPZ rewriting to queries with RD=1 and DO=0.)
However this still doesn't meet your requirement for "a single set of
data", unless you are only talking about zone data, and in that case you
could replicate all the RPZ zone files to all authoritative nameservers,
and then configure each server to specify only one of these in its
"response-policy" configuration?
But the anycast suggestion sounds like it has the most merit? Or at
least it sounds the coolest to me. :-)
Nick.
P.S. I don't think this will be useful to you, but FWIW... if your goal
is simply to have the recursive resolvers use a specific subset of
nameservers for specific zones, then there is yet another option:
static-stub zones. Static-stub zones allow you to effectively override
the authoritative nameserver that will be used for a particular zone. So
you could configure the static-stub zone on the recursive resolver, and
that would point to the local authoritative nameserver(s). However the
main drawback with static-stub zones is that you need to create a
static-stub zone (on the local resolver) for every authoritative zone
that you are doing this with, so it probably isn't practical if you have
many zones or are adding or removing zones frequently?
--
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
