per record responses based on originating IP

[Nick Tait]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220516/3a0c1900/attachment.htm>