using $INCLUDE with views

Stefan Puiu 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
> 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:

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

(The quote is from:
http://www.isc.org/sw/bind/arm92/Bv9ARM.ch06.html#id2564906).

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.

foo.zone:

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

                IN NS   localhost.

foo.common:
@               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.


HTH,
Stefan.

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



More information about the bind-users mailing list