using $INCLUDE with views
stefan.puiu at gmail.com
Tue Oct 10 08:27:34 UTC 2006
On 10/9/06, Bill Moseley <moseley at hank.org> 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
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
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
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: /var/lib/named/foo.common:1: no
TTL specified; using SOA MINTTL instead
Oct 10 11:21:34 tuxws43 named: 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.
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 at hank.org
More information about the bind-users