using $INCLUDE with views

[Bill Moseley]

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

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

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

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

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



    ; Hank.org internal zone file
    $INCLUDE /etc/bind/hank.org.common

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

And the hank.org.common file starts like this (SOA is first record):

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

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

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

    $ dig axfr @63.205.225.170 hank.org

    ; <<>> DiG 9.2.4 <<>> axfr @63.205.225.170 hank.org
    ;; 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 hank.org