Can't update zone: "not authoritative"
Kevin Darcy
kcd at daimlerchrysler.com
Fri Aug 11 21:41:13 UTC 2006
??????? ???????? 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
More information about the bind-users
mailing list