problem with bind9, view and nsupdate

[Michael Dosser]

Hello all,

most probably I have a misconfiguration somewhere in my setup, but I 
cannot figure out where. I have a setup with the following two nameservers:

---------------------------------------------------------------------
ns1:
OS: FreeBSD-4.11-RELEASE-p11
bind9: 9.3.1

ns2:
OS: Debian GNU/Linux 3.1
bind9: 9.2.4-1

Both are started with the following command:
/path/to/named -u bind

Both hosts have a host based firewall. Port 53 udp/tcp is open in both 
directions.

---------------------------------------------------------------------

There is an application on ns2 which updates via nsupdate zonefiles on
ns1. For debugging reasons I left the application aside, and tested as
the user connecting via nsupdate. nsupdate itself is not the problem as
I figured out (and so is the application launching nsupdate). But read, 
after showing you my configs I'll describe the problem.

---------------------------------------------------------------------

Setup on ns1 (named.conf):

acl "nameservers" {
         localhost;
         <ip of ns1>;
	<ip of ns2>;
};
acl "internal" {
	<ips of servers>;
};
acl "customers" {
	<ips of customers>;
};
options {
         directory "/etc/namedb";
         pid-file "/var/run/named/pid";
         query-source address * port 53;
         dump-file "named_dump.db";
         allow-transfer { nameservers; };
         transfer-format many-answers;
         version "DNS server";
         // conform to RFC1035
         auth-nxdomain yes;
         datasize 256m;
         max-ncache-ttl 60;
         recursive-clients 5000;
         listen-on {
                 <ip of nameserver>;
                 127.0.0.1;
         };
};
key "rndc-key" {
         algorithm hmac-md5;
         secret "<secret key>";
};
controls {
         inet 127.0.0.1 port 953
         allow { 127.0.0.1; } keys { "rndc-key"; };
};

key updatekey. {
         algorithm hmac-md5;
         secret "<secret key>";
};

view "internal" {
         match-clients { "internal"; };
         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 "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";
};
---------------------------------------------------------------------
The files named.local, named.internal and named.master are includes not 
managed by nsupdate. The other two (named.primary.conf and 
named.secondary.conf) are managed by nsupdate.
the named.conf on ns2 looks exactly the same. Example entry for
named.primary.conf on ns1 (which is managed by nsupdate):

zone "blasdf.at" IN {
	type master;
	file "/path/to/nsupdate/managed/zones/hosts_blasdf.at";
	allow-update { key updatekey; };
};

and the zone itself:

$ORIGIN .
$TTL 86400      ; 1 day
blasdf.at                IN SOA  ns1.domain.at. dns.domain.at. (
                                 2004081817 ; serial
                                 28800      ; refresh (8 hours)
                                 7200       ; retry (2 hours)
                                 604800     ; expire (1 week)
                                 86400      ; minimum (1 day)
                                 )
                         NS      ns1.domain.at.
                         NS      ns2.domain.at.
                         A       195.69.180.10
                         MX      10 mail.domain.at.
$ORIGIN blasdf.at.



---------------------------------------------------------------------
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.

And this is true for both nameservers (ns1 and ns2). After one day on
ns2 I get the right serial, on ns1 still the old serial.

What is happening here? Where might be the misconfiguration?

Thank you for your help,
Michael Dosser

-- 
The computer revolution is over. The computers won.