0

BIND appears to be looking at the configuration file from top-down and assigning queries to the first matching view based on match-clients. According to http://www.zytrax.com/books/dns/ch7/view.html that's exactly how it's supposed to work.

In my configuration there may be other views that are applicable to a user in the match-clients configuration and I would like to somehow loop through them. If there's no positive hit (from top-down is fine) it should ideally continue on and check the following views.

Is this somehow possible with BIND? Here's an example. In this below configuration a user from 192.168.1.100 or 192.168.200 would both go only to the first view. Instead I want user 192.168.1.200 to also access the second view.

acl "kids" {
        192.168.1.100;
        192.168.1.200;
};

view "kids"{
        response-policy { zone "kids"; };
        match-clients { kids; };
        recursion yes;
        zone "kids" {
                type master;
                file "kids.db";
                allow-query { none; };
        };
};

acl "teens" {
        192.168.1.200;
};

view "teens"{
        response-policy { zone "teens"; };
        match-clients { teens; };
        recursion yes;
        zone "teens" {
                type master;
                file "teens.db";
                allow-query { none; };
        };
};

2 Answers2

2

It can't be done the way you want to achieve it. View matching stops at the first match, and outside views, only one default set of entries can exist. A client can match only one set of zones.

You could have all your views contain all of the zone definitions you want to serve to clients (in your example, 192.168.1.200 should be in "teens" acl only, and the "teens" view would have definition for both the "kids" and the "teens" zones). You may make use of the "include" command to avoid unnecessary duplications, but this is it.

Lacek
  • 6,585
  • 22
  • 28
  • Thank you for the response Lacek. This appears to be a limitation which I will need to overcome in another way. –  Jun 17 '16 at 14:41
  • The only problem with using `include zone` inside multiple views is that if one of the zone is a public-facing Internet and you have to update your hostname in your zone file, you would have to perform multiple RRsets (eg. one in teen view, one in kids view) and that nsupdate cannot discriminate between views (only nsupdate command is `zone name` and the use of `server x.x.x.x` can direct you to a view for RR updates). – John Greene Oct 20 '18 at 14:40
0

Absolutely possible...

acl "kids" {
        192.168.1.100;
};

view "kids"{
        response-policy { zone "kids"; };
        match-clients { kids; };
        recursion yes;
        zone "kids" {
                type master;
                file "kids.db";
                allow-query { none; };
        };
};

acl "teens" {
        192.168.1.200;
};

view "teens"{
        response-policy { zone "teens"; };
        match-clients { teens; };
        recursion yes;
        zone "teens" {
                type master;
                file "teens.db";
                allow-query { none; };
        };
        zone "kids" {
                type master;
                file "kids.db";
                allow-query { none; };
        };
};

for your slaves you need to use tsig and exclude your slaves from views, see How does bind handle allow-notify and match-clients which has an example.

Jacob Evans
  • 7,636
  • 3
  • 25
  • 55