Re: per record responses based on originating IP
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 on behalf of Nick Tait via bind-users Sent: 16 May 2022 13:55 To: BIND Users Mailing List 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
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
Re: per record responses based on originating IP
Thanks for taking the time Nick and Grant, 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. So aside from the anycast suggestion, is there anything else I can look at with bind itself? - I didn't find much with respect to limiting a sortlist response to the first X responses. - Admittedly I don't very well understand the RPZ documentation but I get the feeling it is not the way to go. - Views seem to require duplications of the whole zonefile (this might be the only way to go) - I did find mention of "attach-cache" but this seems to be more about performance than anything else. I could create views for all of my networks - this is automatable. Thanks Angus From: bind-users on behalf of Nick Tait via bind-users Sent: 14 May 2022 02:34 To: bind-users@lists.isc.org Subject: Re: per record responses based on originating IP On 13/05/22 09:02, Grant Taylor via bind-users wrote: On 5/12/22 2:41 PM, Nick Tait via bind-users wrote: This sounds like exactly the sort of use case for Response Policy Zones: How are you going to have RPZ return different addresses for different clients? Are you suggesting use different RPZs with different contents for different clients? Yes, although now that I think through the details it turns out to be much messier than I first thought, because there doesn't seem to be a way to specify "not" in the RPZ... Also I should point out that I'm assuming that a PASSTHRU result in one RPZ will still result in subsequent RPZs being processed. I haven't actually tested this, so its possible I'm misunderstanding the documentation? Anyway in the interests of following this all the way though, let's assume you had 3 clients and you wanted them to each receive a different answer to the query "www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>": Suppose their IP addresses are: A = 192.0.2.10 B = 192.0.2.20 C = 192.0.2.30 Then, if I'm not mistaken, you could create 3 RPZ zones: Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc): ; Don't overwrite the answer for queries received from clients B & C 32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru. 32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru. ; Change the answer to the question www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0> www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0> IN A 10.0.0.1 Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc): ; Don't overwrite the answer for queries received from clients A & C 32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru. 32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru. ; Change the answer to the question www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0> www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0> IN A 10.0.0.2 Zone file for "c.rpz.mylocaldomain.com" contains (in addition to
Re: per record responses based on originating IP
On 5/15/22 7:28 AM, Angus Clarke wrote: Hi Grant Hi Angus, maybe, I'm reading up ... poking around the manual, are you alluding to the "sortlist" directive? Yes, that's what I was referring to. So the concern with returning an ordered RRset is that the set could be large: Okay. I assume that's opposed to returning small distinct / unique RR sets with per client granularity. The intention is that each private site/network will have its own DNS server pair and that local recursors resolve all private zones from that local pair. So things like NS records would be in scope for the ordered RRset response. With more sites come more DNS pairs and therefore more NS records to be added to the RRset. Maybe I can limit a RRset response to the first X number of entries? Hum. With this description in mind, I'd be tempted to do something with the anycast methodology that was recently discussed. Return one small RRset that references the fixed set of any cast NS IPs. Then routing at each site will get clients to the local instance of those anycasted IPs. This would probably scale a lot better. Thanks :-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: per record responses based on originating IP
Hi Grant > Before stepping up to views I'd stop to ask the question, would > returning multiple IPs in a preferred sort order suffice? maybe, I'm reading up ... > BIND has the ability to sort RRs differently based on different client > criteria. poking around the manual, are you alluding to the "sortlist" directive? > If sorting of replies won't suffice, please provide a hypothetical > example of a couple of different clients & responses for an example RR. So the concern with returning an ordered RRset is that the set could be large: The intention is that each private site/network will have its own DNS server pair and that local recursors resolve all private zones from that local pair. So things like NS records would be in scope for the ordered RRset response. With more sites come more DNS pairs and therefore more NS records to be added to the RRset. Maybe I can limit a RRset response to the first X number of entries? Thanks Angus From: bind-users on behalf of Grant Taylor via bind-users Sent: 12 May 2022 18:11 To: bind-users@lists.isc.org Subject: Re: per record responses based on originating IP On 5/12/22 6:30 AM, Angus Clarke wrote: > Hello Hi, > With bind (and others) it seems that DNS views are the way to go, Before stepping up to views I'd stop to ask the question, would returning multiple IPs in a preferred sort order suffice? BIND has the ability to sort RRs differently based on different client criteria. > Does bind have some simple way to respond differently based on source > address but on a per record basis? Or perhaps include a baseline zone in > a view and separately include differences for that view - something like > this perhaps? If sorting of replies won't suffice, please provide a hypothetical example of a couple of different clients & responses for an example RR. -- Grant. . . . unix || die -- 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
Re: per record responses based on originating IP
On 13/05/22 09:02, Grant Taylor via bind-users wrote:
On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:
This sounds like exactly the sort of use case for Response Policy Zones:
How are you going to have RPZ return different addresses for different
clients? Are you suggesting use different RPZs with different
contents for different clients?
Yes, although now that I think through the details it turns out to be
much messier than I first thought, because there doesn't seem to be a
way to specify "not" in the RPZ...
Also I should point out that I'm assuming that a PASSTHRU result in one
RPZ will still result in subsequent RPZs being processed. I haven't
actually tested this, so its possible I'm misunderstanding the
documentation?
Anyway in the interests of following this all the way though, let's
assume you had 3 clients and you wanted them to each receive a different
answer to the query "www.example.com":
Suppose their IP addresses are:
A = 192.0.2.10
B = 192.0.2.20
C = 192.0.2.30
Then, if I'm not mistaken, you could create 3 RPZ zones:
Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc):
; Don't overwrite the answer for queries received from clients B & C
32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
; Change the answer to the question www.example.com
www.example.com IN A 10.0.0.1
Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc):
; Don't overwrite the answer for queries received from clients A & C
32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
; Change the answer to the question www.example.com
www.example.com IN A 10.0.0.2
Zone file for "c.rpz.mylocaldomain.com" contains (in addition to SOA, etc):
; Don't overwrite the answer for queries received from clients A & B
32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
; Change the answer to the question www.example.com
www.example.com IN A 10.0.0.3
And then configure BIND to use all three RPZs:
response-policy {
zone "a.rpz.mylocaldomain.com";
zone "b.rpz.mylocaldomain.com";
zone "c.rpz.mylocaldomain.com";
};
Scalability is obviously a challenge with this particular solution! :-(
So on reflection, there are probably better solutions to the problem
that you are trying to solve. Although I don't personally have
experience with it, wonder if "dnsmasq" might do what you need?
Thanks,
Nick.
--
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
Re: per record responses based on originating IP
On 5/12/22 2:41 PM, Nick Tait via bind-users wrote: This sounds like exactly the sort of use case for Response Policy Zones: How are you going to have RPZ return different addresses for different clients? Are you suggesting use different RPZs with different contents for different clients? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: per record responses based on originating IP
On 13/05/2022 12:30 am, Angus Clarke wrote: Does bind have some simple way to respond differently based on source address but on a per record basis? Or perhaps include a baseline zone in a view and separately include differences for that view - something like this perhaps? Hi Angus. This sounds like exactly the sort of use case for Response Policy Zones: https://bind9.readthedocs.io/en/v9_18_2/reference.html#response-policy-zone-rpz-rewriting Nick. -- 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
Re: per record responses based on originating IP
On 5/12/22 6:30 AM, Angus Clarke wrote: Hello Hi, With bind (and others) it seems that DNS views are the way to go, Before stepping up to views I'd stop to ask the question, would returning multiple IPs in a preferred sort order suffice? BIND has the ability to sort RRs differently based on different client criteria. Does bind have some simple way to respond differently based on source address but on a per record basis? Or perhaps include a baseline zone in a view and separately include differences for that view - something like this perhaps? If sorting of replies won't suffice, please provide a hypothetical example of a couple of different clients & responses for an example RR. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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
