On 10/9/06, Bill Moseley wrote:
> 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
> world.

In your first email you didn't mention that you had a slave server for
the internal/external version of the zone that was failing to fetch
the updated one. That was confusing. Also, see below.

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

I think this is wrong. The 9.2 ARM
(http://www.isc.org/index.pl?/sw/bind/arm92/) says:

If origin is specified the file is processed with $ORIGIN set to that
value, otherwise the current $ORIGIN is used.

The origin and the current domain name revert to the values they had
prior to the $INCLUDE once the file has been read.

(The quote is from:

The origin should default to 'hank.org.' before inclusion and should
be restored to that. However, I don't think the same goes for the
'current domain'.

In fact, I tried a similar setup (I have BIND 9.2.3 on this machine,
it's not for production purposes), and this is what I see in syslog:

Oct 10 11:21:34 tuxws43 named[9050]: /var/lib/named/foo.common:1: no
TTL specified; using SOA MINTTL instead
Oct 10 11:21:34 tuxws43 named[9050]: dns_master_load: foo.zone:3: no
current owner name

It's obvious the 'foo' zone failed to load. A query for the NS record
of the zone returns SERVFAIL, as expected.


$INCLUDE "/var/lib/named/foo.common"

IN NS localhost.

@ IN SOA localhost. root (
4 ; serial
2D ; refresh
4H ; retry
6W ; expiry
1W ) ; minimum

Basically, very similar to what you have. I'd check those logs once again.

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

See above - I think you have a different issue here. Normally, I don't
think there should be problems (unless you want to be abel to
dynamically update one version of the zone using DDNS), however, you
have to write the zone file properly - i.e., add an owner to the NS
records after the $INCLUDE:

hank.org. 1D IN NS ns1.twisted4life.com.
1D IN NS lucifer.logilune.com.


> --
> Bill Moseley
> moseley@hank.org