Trouble updating zones in a multi-view scenario
Justin Shore
justin at justinshore.com
Thu Nov 13 04:11:03 UTC 2008
I've been putting up with a weird issue for a few months. I'm running
9.5.1b2 on 2 servers in a simple master/slave setup. I have 2 views
configured, one trusted and one not trusted. I use ACLs to decide what
the querying IP is. The main difference between the views is that I
allow recursion in the trusted zone. To shorten the overall config and
I have 3 separate conf files that collectively load all my forward and
reverse zones. I include these 3 conf files in both my trusted and
non-trusted zones. It trims my named.conf by about 2000 lines that way.
Plus I can more easily generate the external files with a script.
It's a fairly simple config. The config on both boxes is practically
identical. The only difference on the slave is that the config for the
zones have all the pertinent slave config to point at the master. All
of this is loaded in a chroot environment.
The problem I'm running into is that when I update a zone and issue a
rndc reload, only the trusted view loads the update. The non-trusted
view never gets the update. I have to literally restart the daemon to
get the non-trusted view to load the updated zone. This problem happens
on both the master and on the slave. I have to issue the rndc reload on
the master before restarting or the slave will not download a new copy
of the zone (ie a restart would fix the master but the slave won't get a
new copy until I bump the SN again and the issue the reload on the
master; then I still have to restart the slave). It's rather weird.
I posted my config on 11/1 at 13:03 (subject: Re: in-addr.arpa problem)
so I won't waste list bandwidth on that again. Any ideas why this is
going on? Is this expected behavior? Am I not doing something correct?
It's not a show-stopper but I tend to forget fairly often. I usually
remember when I get a call saying that everything works locally (trusted
view) and doesn't work from the outside world (non-trusted view).
Thanks
Justin
More information about the bind-users
mailing list