Bind 9.2.4, views, and different class Bs

[Kevin Darcy]

Clear as mud. Is that 3 views, 4 views or 5? Based on what you wrote 
below, I'm thinking you mean 5 views -- 1 "anti-virus" view for each of 
3 backbone routers, then a generic "anti-virus" view, and lastly a 
regular (i.e. not "anti-virus") view for everything else.

Why don't you just draw up a matrix of which sets of clients need to see 
which versions of the namespace? Might make it easier to plan your view 
configuration.

I think the important part you're missing too, is that there is no "fall 
through" for views. The nameserver tries to match each view in sequence 
and once a match is found, that's the view that is given to the client 
*for*everything*. So if you want, say, 168.192.in-addr.arpa available 
for different clients matching different views, you need to define and 
maintan a 168.192.in-addr.arpa for *every* view that those clients will 
match. The nameserver isn't going to match one view, notice that the 
zone containing the name being queried isn't defined in that view, and 
then "fall through" to other views until it finds a name match. That's 
just not how the algorithm works.

                                                                         
                              - Kevin

carcarx at hotmail.com wrote:
> Here's what we're hoping to do:
>
> Associate 1 view with an anti-virus zone for each backbone router  (3
> of them) and then 1 more for the rest of the world.
> All the IP addresses on our network are included within those three
> views.
> Then, the rest of the zones, equally visible inside and outside our
> network, are included in the
> match-clients { "any";}; view.
>
>
> Ideas?
>
> Thanks!
>
> On Oct 30, 9:27 am, "carc... at hotmail.com" <carc... at hotmail.com> wrote:
>   
>> We're running Bind 9.2.4 on RedHat EL3. We have several private IP
>> address spaces as class Bs.
>>
>> All is well without any view "blocks". When I add some views, one
>> representation
>> of an anti-virus caching zone that has a different view depending on 4
>> different IP originations,
>> but the rest surrounded by a view with "match-clients { "any";};
>>
>> Strangely the zone containing 10.in-addr.arpa and 168.192.in-addr.arpa
>> aren't loaded, evidently,
>> but there are no error messages in syslog
>>
>> Any ideas what might be happening?
>>
>> Thanks!
>>     
>
>
>
>
>
>