per record responses based on originating IP

Mon May 16 08:05:20 UTC 2022

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 <bind-users-bounces at lists.isc.org> on behalf of Nick Tait via bind-users <bind-users at lists.isc.org>
Sent: 14 May 2022 02:34
To: bind-users at lists.isc.org <bind-users at 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&data=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D&reserved=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&data=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D&reserved=0>
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F&data=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D&reserved=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&data=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D&reserved=0>
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F&data=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D&reserved=0> 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<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F&data=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D&reserved=0>
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F&data=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D&reserved=0> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220516/b2ea6c4d/attachment-0001.htm>