unable to suppress the notify from slave back to the master

[Mark Andrews]

> Greeting all; Does anyone have any thoughts on this... Thanks for your time!
> 
> Problem: I have a slave Bind which sends a notify back to the master, which t
> he
> master rightly refuses. I'm trying to suppress this slave-towards-master
> notify. The slave already has the global 'notify no' option; I even tried
> 'notify no' and 'notify explicit' within the zone. Also, there are many many
> zones so I'd rather not have to put 'notify no' into each zone, when a global
> 'notify no' should do it. At this point, I suspect I'm fundamentally
> misunderstanding what's going on... maybe this isn't a 'notify' problem at al
> l.
> :)
> 
> Background:
> 
> These are two Bind 9.4.1-P1 servers on seperate Linux systems. In the logs
> below, I've substituted PRIMARY, PRIMARY_IP, SECONDARY, and SECONDARY_IP for
> hostnames and IPs. Both Binds use views, and use TSIG to identify each other.
> When I change a zone on the master, it correctly notifies the slave. The slav
> e
> initiates a zone transfer using TSIG and retrieves the correct view.
> 
> Excerpts from the Primary's config...
> 
>  view internal_view {
>    allow-transfer {
>      key "intview.";  // TSIG!
>    };
>    zone "0.0.10.in-addr.arpa" { 
>      type master;
>      file "zones/0/0.0.10.in-addr.arpa.int";
>      allow-query { internal_ips; };
>    };
>  };
> 
> Excerpts from the Secondary's config...
> 
>  options {
>    notify no;
>  }
>  view internal_view {
>    server PRIMARY_IP {
>      keys { "intview."; }; // TSIG!
>    };
>    zone "0.0.10.in-addr.arpa" {
>      type slave;
>      masters { PRIMARY_IP; };
>      file "zones/0/0.0.10.in-addr.arpa.int";
>      allow-query { internal_ips; };
>    };
>  };
> 
> Logs (via syslog) follow with my commentary interspersed...
> 
> Apr  4 10:27:27 PRIMARY named[4086]: general: info: zone
> 0.0.10.in-addr.arpa/IN/internal_view: loaded serial 2008040502
> Apr  4 10:27:27 PRIMARY named[4086]: notify: info: zone
> 0.0.10.in-addr.arpa/IN/internal_view: sending notifies (serial 2008040502)
> Apr  4 10:27:27 SECONDARY named[2453]: notify: info: client PRIMARY_IP#32876:
> view internal_view: received notify for zone '0.0.10.in-addr.arpa': TSIG
> 'intview'
> 
> -- so on the master, I had updated the zone serial and issued
> -- a reload via rndc and the secondary sees the notify.
> 
> Apr  4 10:27:27 SECONDARY named[2453]: general: info: zone
> 0.0.10.in-addr.arpa/IN/internal_view: refresh: unexpected rcode (REFUSED) fro
> m
> master PRIMARY_IP#53 (source SECONDARY_IP#0)
> 
> -- did the slave just try to send a notify to the master??

	No.  The slave sent a refresh query (SOA) to the master to which
	it  returned REFUSED.

	Add "key intview;" to the master's allow-query.

	Mark
 
> Apr  4 10:27:27 SECONDARY named[2453]: general: info: zone
> 0.0.10.in-addr.arpa/IN/internal_view: Transfer started.
> Apr  4 10:27:27 SECONDARY named[2453]: xfer-in: info: transfer of
> '0.0.10.in-addr.arpa/IN/internal_view' from PRIMARY_IP#53: connected using
> SECONDARY_IP#45059
> Apr  4 10:27:27 PRIMARY named[4086]: xfer-out: info: client SECONDARY_IP#4505
> 9:
> view internal_view: transfer of '0.0.10.in-addr.arpa/IN': AXFR-style IXFR
> started: TSIG intview
> Apr  4 10:27:27 SECONDARY named[2453]: xfer-in: info: transfer of
> '0.0.10.in-addr.arpa/IN/internal_view' from PRIMARY_IP#53: end of transfer
> Apr  4 10:27:27 PRIMARY named[4086]: xfer-out: info: client SECONDARY_IP#4505
> 9:
> view internal_view: transfer of '0.0.10.in-addr.arpa/IN': AXFR-style IXFR end
> ed
> Apr  4 10:27:27 SECONDARY named[2453]: general: info: zone
> 0.0.10.in-addr.arpa/IN/internal_view: transferred serial 2008040502: TSIG
> 'intview'
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org