Here's some extracts from my named.conf, as an example. Just remember, if
you have any zones in a view, then you must also add that zone to all the
other views, otherwise you'll end up not serving those zones at all to the
other views. =)
[snip]
Your conf file shows that it is set up as:
Define a view
Now allocate zonefiles to it
What if you host multiple domains, and the view you want to give them
overlap? Is it not possible to do:
Make a zone file
Put views in it just for that zone
Make another zone file for a different domain
Put view in it that overlap the first zoenfiles, but won't conflict
because they are in a different zone.
By overlap I mean something like this:
Zone1: 'internal' = 10.0.1.0/24 + 'external' = 192.168.1.0/24
Zone2: 'internal' = 10.0.0.0/16 + 'external' = 192.168.0.0/16
Zone3: 'internal' = 127.0.0.0/8 + 'external' = 10.0.0.0/16
If you're referring to clients overlapping, such as:
192.168.0.0/16 sees internal for domain1, external for domain2
10.0.0.0/8 sees external for domain1, external for domain2
172.16.0.0/12 sees external for domain1, internal for domain2
Then I think you'll have to define a view for each combination, and
include whichever zonefiles are appropriate for that view.
Not really, because you define the views inside the zonefiles, instead of
defining the sonefiles inside the view. Each zone has full control over
what is a zone for it and what isn't.
Bind's currnet datapath looks like this:
Incoming query -> Check src address -> Enter view -> perform query
What I think it SHOULD be like is:
Incoming query -> Check domain being queried -> Enter zone file -> Perform
query -> If 'view' is defined against the RR, check src address and reply
appropriately.
If you're referring to clients overlapping, such as:
192.168.0.0/16 sees internal for domain1, external for domain2
10.0.0.0/8 sees external for domain1, external for domain2
172.16.0.0/12 sees external for domain1, internal for domain2
Then I think you'll have to define a view for each combination, and
include whichever zonefiles are appropriate for that view.
I use a 'match-clients any' statement in the last view. Everything falls
into there after the other views are matched. EG:
view "public" {
match-clients {
any;
};
zone...
};
Internal and external have their own views of sensitive zones, but they
share the root cache and other public zones.
