On Mon, Oct 09, 2006 at 07:12:26PM +0300, Stefan Puiu wrote:
> your post is a bit confusing, since you seem to be mixing up views
> with master/slave operation - the two are different issues, as Barry
> pointed out.

No, I don't think I'm mixing them up. I'm using the views so my
internal LAN sees a (slightly) different zone than the rest of the

What I did do *in error* was copy my master's zone file to the slave
as a template and then modified it as the slave. I, for some crazy
reason, left in the views in the slave but changed each zone to "type

So, what seems to have happened is when I updated the master the save
would see the notification, but then only reloaded its "internal" view
and not the "external" view. So, requests to that slave from external
sources never say the updated zone. Oops.

It was that mistake along with the issue below that made me wonder
about how the serial number is tested with views (when used correctly
in the master, that is).

It's not worth discussion since it's an error that has now been

> >I moved the SOA out of the common file and into each of the two zone
> >files and then it worked fine.
> >
> >Was that because I had two zone files (for the same domain) with the
> >same SOA serial number?

> One thing that comes to my mind is that the SOA has to be the first
> record in any zone file. So if you $include the SOA file at the end of
> one of the zones, for example, it won't work. Check your system logs
> for any complaints from BIND.

Nothing was reported in the logs other than normal startup and
transfer notifications. And the SOA was the first record in the
included file.

That is, the zones looked like this:

; Hank.org external zone file
$INCLUDE /etc/bind/hank.org.common

; External zone sees extra NS servers
1D IN NS ns1.twisted4life.com.
1D IN NS lucifer.logilune.com.

; Hank.org internal zone file
$INCLUDE /etc/bind/hank.org.common

; Internal Zone sees internal machines
bumby 1D IN NS
ap 1D IN NS
dev1 1D IN NS

And the hank.org.common file starts like this (SOA is first record):

@ 1D IN SOA ns1 root (
2006100806 ; serial
6H ; refresh
1H ; retry
1W ; expiry
1D ) ; minimum

;; hank.org's IP number
[... more records common to both zones ...]

When done that way bind starts normally with no errors in the logs,
and on the internal LAN I can run:

$ dig axfr @ hank.org

and see the "internal" zone, but when run on a remote
machine I get:

$ dig axfr @ hank.org

; <<>> DiG 9.2.4 <<>> axfr @ hank.org
;; global options: printcmd
; Transfer failed.

Putting the SOA in *each* zone file solved that problem and I can now
axfr from a remote machine.

But, I think it makes sense that the SOA would have to be in the zone
file and not the $included one -- as any changes in the top zone file
would require a serial number bump, and, of course, changes can happen
in the internal view of a zone and not in the external view.

Bill Moseley