using $INCLUDE with views

Bill Moseley moseley at
Mon Oct 9 17:35:47 UTC 2006

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:

    ; external zone file
    $INCLUDE /etc/bind/

                    ; External zone sees extra NS servers
                    1D IN NS
                    1D IN NS

    ; internal zone file
    $INCLUDE /etc/bind/

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

And the file starts like this (SOA is first record):

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

                    ;;'s IP number
                    1D IN A
                    [... 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 @

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

    $ dig axfr @

    ; <<>> DiG 9.2.4 <<>> axfr @
    ;; 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
moseley at

More information about the bind-users mailing list