problem with bind9, view and nsupdate
Barry Margolin
barmar at alum.mit.edu
Tue Aug 2 21:44:02 UTC 2005
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 ***
More information about the bind-users
mailing list