Can't update zone: "not authoritative"

[Kevin Darcy]

??????? ???????? wrote:
> Hi.
> I have two NS servers, one master, another slave.
> And here are the problem: after launching both servers I found at slave
> server in notify.log file such lines:
>
> -------------8<---------------------------------------------------------
> Aug 11 16:30:40.005 notify: received notify for zone 'abc': not
> authoritative
> Aug 11 16:30:40.512 notify: received notify for zone 'xyz'
> -------------8<---------------------------------------------------------
>
> It means, that domain zone 'abc' doen't updates from master server, when
> master updates one.
> Now, look at config files, and later I'll show you something interesting.
>
> master's config file:
> -------------8<---------------------------------------------------------
> options {
>         version "my_own_version";
>         directory "/var/named";
>
>         forward first;
>         forwarders {
>                 192.168.0.13 ;
>                 192.168.0.8;
>         };
>
>         listen-on-v6 { none; };
>         listen-on { 127.0.0.1; 192.168.0.199 ; };
>
>         pid-file "/var/run/named/named.pid";
> };
>
> logging {
>         channel notify_ch {
>                 file "/var/log/bind/notify" versions 3 size 10000k;
>                 severity debug;
>                 print-time yes;
>                 print-category yes;
>         };
>         category notify { notify_ch; };
> };
>
> view "aaa" {
>         zone "abc" IN {
>                 type master;
>                 file "master/abc.zone";
>
>                 allow-transfer { any; };
>                 allow-update { any; };
>
>                 notify explicit;
>                 notify-source 192.168.0.199;
>                 also-notify { 192.168.0.113; };
>         };
> };
>
> view "bbb" {
>         zone "xyz" IN {
>                 type master;
>                 file "master/xyz.zone";
>
>                 allow-transfer { any; };
>                 allow-update { any; };
>
>                 notify explicit;
>                 notify-source 192.168.0.199;
>                 also-notify { 192.168.0.113; };
>         };
> };
> -------------8<---------------------------------------------------------
>
> domain zones at master NS server:
> -------------8<---------------------------------------------------------
> # cat abc.zone
> $TTL 3600       ; 1 hour
> @       IN      SOA     abc.    bindmaster.abc. (
>                                         2006081055 ; serial
>                                         2H       ; refresh (2 hours)
>                                         15M      ; retry (15 minutes)
>                                         2H       ; expire (2 hours)
>                                         15M       ; negative-caching (15
> minutes)
>                                 )
>                 IN      A       192.168.0.199
>                 IN      NS      ns.abc.
>                 IN      NS      ns2.abc.
> $ORIGIN abc.
> ns              IN      A       192.168.0.199
> ns2             IN      A       192.168.0.133
>
> # cat xyz.zone
> $TTL 3600       ; 1 hour
> @       IN      SOA     xyz.    bindmaster.xyz. (
>                                         2006081044 ; serial
>                                         2H       ; refresh (2 hours)
>                                         15M      ; retry (15 minutes)
>                                         2H       ; expire (2 hours)
>                                         15M       ; negative-caching (15
> minutes)
>                                 )
>                 IN      A       192.168.0.199
>                 IN      NS      ns.xyz.
>                 IN      NS      ns2.xyz.
> $ORIGIN xyz.
> ns              IN      A       192.168.0.199
> ns2             IN      A       192.168.0.133
> -------------8<---------------------------------------------------------
>
> slave's config file:
> -------------8<---------------------------------------------------------
> options {
>         version "my_own_version";
>         directory "/var/named";
>
>         forward first;
>         forwarders {
>                 192.168.0.13 ;
>                 192.168.0.8;
>         };
>
>         listen-on-v6 { none; };
>         listen-on { 127.0.0.1; 192.168.0.113 ; };
>
>         pid-file "/var/run/named/named.pid";
> };
>
> logging {
>         channel notify_ch {
>                 file "/var/log/bind/notify" versions 3 size 10000k;
>                 severity debug;
>                 print-time yes;
>                 print-category yes;
>         };
>         category notify { notify_ch; };
> };
>
> view "first" {
>         zone "abc" IN {
>                 type slave;
>                 file "slave/abc.zone";
>                 masters { 192.168.0.199; };
>
>                 # transfer mechanism
>                 transfer-source 192.168.0.113;
>         };
> };
>
> view "second" {
>         zone "xyz" IN {
>                 type slave;
>                 file "slave/xyz.zone";
>                 masters { 192.168.0.199; };
>
>                 # transfer mechanism
>                 transfer-source 192.168.0.113;
>         };
> };
> -------------8<---------------------------------------------------------
>
> and now interesting thing: I'll swap order of view statement, like this:
> -------------8<---------------------------------------------------------
> view "second" {
>         zone "xyz" IN {
>                 type slave;
>                 file "slave/xyz.zone";
>                 masters { 192.168.0.199 ; };
>
>                 # transfer mechanism
>                 transfer-source 192.168.0.113;
>         };
> };
>
> view "first" {
>         zone "abc" IN {
>                 type slave;
>                 file "slave/abc.zone";
>                 masters { 192.168.0.199; };
>
>                 # transfer mechanism
>                 transfer-source 192.168.0.113;
>         };
> };
> -------------8<---------------------------------------------------------
>
> and we'll receive another lines in nofity.log:
> -------------8<---------------------------------------------------------
> Aug 11 16:30:40.005 notify: received notify for zone 'abc'
> Aug 11 16:30:40.512 notify: received notify for zone 'xyz':  not
> authoritative
> -------------8<---------------------------------------------------------
>
> now, domain zone 'abc' have been updated, but zone 'xyz' doesn't.
>
> Oh, here are another strange thing: if I will declare both zones in one view
> like this:
> -------------8<---------------------------------------------------------
> view "second" {
>         zone "xyz" IN {
>                 type slave;
>                 file "slave/xyz.zone";
>                 masters { 192.168.0.199 ; };
>
>                 # transfer mechanism
>                 transfer-source 192.168.0.113;
>         };
>
>         zone "abc" IN {
>                 type slave;
>                 file "slave/abc.zone";
>                 masters { 192.168.0.199; };
>
>                 # transfer mechanism
>                 transfer-source 192.168.0.113;
>         };
> };
>
> view "first" {
>
> };
> -------------8<---------------------------------------------------------
>
> I will receive what I want:
> -------------8<---------------------------------------------------------
> Aug 11 16:30:40.005 notify: received notify for zone 'abc'
> Aug 11 16:30:40.512 notify: received notify for zone 'xyz'
> -------------8<---------------------------------------------------------
> but, as I think, this is wrong decision of bind server.
>
>   
Well, you've made it impossible to analyze your examples meaningfully 
because you've left out the "match" statements for the views (e.g. 
"match-clients"). BIND will use the first view that *matches* the 
incoming query or notify packet. Obviously, then, if you move zones 
around between views, sometimes the notifies will go to the same view 
that contains a definition for the corresponding zone (in which case 
things work) or, other times they'll go to a view that doesn't contain 
any such definition, in which case you'll get the "not authoritative" error.

- Kevin