[dns-wg] Resolve DNS Queries Based on Source IPs in BIND (NEED ADVISE)

On Tue, Nov 19, 2019 at 05:12:09AM +0000, Md. abdullah Al naser via dns-wg wrote:
> Hi everyone, I hope you all are fine. I am new in the mailing list and looking for an advise. If this mailing-list is not suitable for my below query then please pardon me. 
> I am stuck in a situation and looking for a solution. My scenario is like below.
> I want to block some websites for my all users.
> For example:www.abc.comwww.xyz.cometc
> I did it using Response Policy Zone (RPZ) in BIND.        response-policy {zone "rpz";};rrset-order { order cyclic; };
> zone "rpz" {    type master;    allow-query { any; };    file "/etc/bind/rpz.db";    }; In my RPZ zone file I created CNAME entries for above mentioned FQDNs which have been pointed to discard.websites.com www.abc.com IN CNAME discard.websites.com.;www.xyz.com IN CNAME discard.websites.com.;
> And later on, in websites.com zone file (which is another fake zone) I created an A record for discard.websites.com which has been pointed to 192.168.127.127 (a fake IP). discard   IN  A   192.168.127.127;
> In this way all the dns requests from my all users for above mentioned sites are resolved to 192.168.127.127 and the real websites are unreachable.
> (N.B. I am not worry about the situation when users change their DNS IP to any open resolver and can access the websites.)
> Everything was going fine. By this time another requirement came into the picture. Now I need to block the mentioned websites for some specific users (based on source IP).
> So in my RPZ configuration I specified the users source IP block like below.
> zone "rpz" {    type master;    allow-query { 192.168.10.0/24; };    file "/etc/bind/rpz.db";    };
> At this point the dns queries from the specified block 192.168.10.0/24 are resolved to my fake ip and all other requests from rest of IP blocks are dropped (as expected as per configuration).
> But I want to do like this, the dns queries from 192.168.10.0/24 blocks will be matched with RPZ zone and other requests from rest of IPs will bypass the RPZ configuration and will match my general "allow-query {any;}" statement mentioned in named.conf file.
> Will the logic work as I stated above?? Any comments from the experts will be great for me.
> (N.B. I came to know that, resolving different IP based on different source can be possible in KNOT DNS, but I would be happy to do it in BIND (if possible).

(1) You can implement custom configurations for different subnets using
views in BIND. Read about views and match-clients if you want to match
by client IP. You may want to also make use of attach-cache to share a
single cache among the views in your case.

(2) Some years ago, I proposed and implemented as a branch for BIND an
RPZ extension with policy action "rpz-skipzone.", but it was not
standardized as we're still stuck with RPZ not moving in the dnsop (the
current draft limits to what has been implemented in BIND so far).

With "rpz-skipzone.", RPZ processing can be skipped to the next RPZ zone
in order for the query.

E.g., with two policy zones like this:

(i) rpz1.zone:

24.0.10.168.192.rpz-client-ip CNAME rpz-skipzone.
1.0.0.0.0.rpz-client-ip CNAME rpz-passthru.
1.0.0.0.128.rpz-client-ip CNAME rpz-passthru.

(ii) rpz2.zone:

www.abc.com IN CNAME discard.websites.com.

RPZ matches the longest prefix trigger's rule first with the client IP,
so clients in 192.168.10.0/24 will move to processing rules in rpz2
whereas the rest of the clients don't have RPZ applied at all due to
rpz-passthru.

Maybe "rpz-skipzone." will get picked up later after the current
situation with the RPZ draft progresses somehow. You may be able to
request and receive a patch for "rpz-skipzone." from ISC, but note that
it is non-standard and you won't be able to share your policy zones with
other implementations. (1) is your best bet.

		Mukund