problem with bind9, view and nsupdate

[Barry Margolin]

In article <dcnmst$1cjh$1 at sf1.isc.org>, Michael Dosser <mic at strg.at> 
wrote:

> view "customers" {
>          match-clients { "customers"; };
>          recursion yes;
>          include "named.local";
>          include "named.internal";
>          include "named.master";
>          include "/path/to/nsupdate/managed/named.primary.conf";
>          include "/path/to/nsupdate/managed/named.secondary.conf";
> };
> 
> view "external" {
>          match-clients { "any"; };
>          recursion no;
>          include "named.local";
>          include "named.internal";
>          include "named.master";
>          include "/path/to/nsupdate/managed/named.primary.conf";
>          include "/path/to/nsupdate/managed/named.secondary.conf";
> };

It looks like the only difference between your two views is the 
"recursion" option.  If that's the case, don't use views; put:

  allow-recursion { customers; };

in the global options section.

> ---------------------------------------------------------------------
> Problem description:
> 
> If I update blasdf.at and add a new A record (or any other record) with
> nsupdate, the serial gets automagically - as expected - bumped higher by
> 1, so with the above example I get 2004081818. ns2 as a slave gets also
> the new serial and the new A record.
> 
> If I launch dig on one of the nameservers all looks good:
> 
> $ dig soa blasdf.at @localhost|grep -A 2 "ANSWER SECTION"
> ;; ANSWER SECTION:
> blasdf.at.               86400   IN      SOA     ns1.domain.at.
> dns.domain.at. 2004081818 28800 7200 604800 86400
> 
> But if I dig from a host defined in view external I get the old serial:
> 
> $ dig soa blasdf.at @ns1.domain.at|grep -A 2 "ANSWER SECTION"
> ;; ANSWER SECTION:
> blasdf.at.               86400   IN      SOA     ns1.domain.at.
> dns.domain.at. 2004081817 28800 7200 604800 86400
> 
> If I dig from a host defined in view internal, I get the right serial,
> but not if I dig from a host in view customers.

When you use views, there are multiple copies of each zone in memory.  
Only the copy in the view that matches the nsupdate client gets updated.

This is true even if they initially get loaded from the same file.  
Things will get really confusing if you make updates in both views, and 
then named writes them each out to the same zone file -- only the view 
whose changes are written last will be saved in the file.  The next time 
you restart named or do rndc reload the views will get back in sync, 
although one set of changes will have been lost.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***