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
