Hello I found that knot's geoip module can modify responses to individual records based on the source address of the client through the module's "net" directive and have successfully tested the modification of NS responses based on the client's source subnet - it seems to do exactly what I want.
I had a quick check of the bind geoip module but the example given in the documentation suggests presenting an entire zone as an alternative view. Thanks for taking the time with me on my quest, but I think I'll further investigate knot at this time. knot geoip module overview: https://blog.apnic.net/2018/11/14/geoip-in-knot-dns-2-7/ Thanks Angus ________________________________ From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Nick Tait via bind-users <bind-users@lists.isc.org> Sent: 16 May 2022 13:55 To: BIND Users Mailing List <bind-users@lists.isc.org> Subject: Re: per record responses based on originating IP 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
