using $INCLUDE with views

Stefan Puiu stefan.puiu at
Tue Oct 10 08:27:34 UTC 2006

On 10/9/06, Bill Moseley <moseley at> 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:
>     ; external zone file
>     $INCLUDE /etc/bind/
>                     ; External zone sees extra NS servers
>                     1D IN NS
>                     1D IN NS

I think this is wrong. The 9.2 ARM
( 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 '' 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: 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:       1D IN NS
                     1D IN NS


> --
> Bill Moseley
> moseley at

More information about the bind-users mailing list