multiple `zone' clauses for a single domain?

Matthew Seaman m.seaman at
Fri Nov 25 21:56:29 UTC 2011

On 25/11/2011 16:59, Marek Kozlowski wrote:
> Is it allowed to use a few `zone' clauses for a single domain? Is
> something like this correct:
> zone "" in {
>         type master;
>         file "pri/";
>         allow-query { any; };
>         allow-transfer { xfer; };
> };
> zone "" in {
>         type master;
>         file "pri/";
>         allow-query { trusted; };
>         allow-transfer { xfer; };
> };
> where `' stores information on public hosts from my
> domain while `' stores hosts that should be
> visible/known only for trusted host?

This doesn't work -- you can't mix the data from two different zone
files in this way.  One zone file per zone is the rule. Although that
file can include others, this doesn't really provide scope for the sort
of thing you want to do.

> Should I duplicate all records from `' in
> `'?

Duplicating records like that is annoying and error prone.  It's a
better strategy to create separate zones for your private internal and
your public data.  So you can have published to the world,
and example.local just for your private stuff.  Or you could create a
sub-domain of your globally published data eg.
(Although in this case, if you delegate the private zone from the public
one, the delegation records and any glue will be publicly available,
which may not be desirable.)

> Do I *have* to use views to deal with such distinction or can I specify
> it just as above without views?

If you need to give different answers from the same server depending on
who is asking the question, then, yes, you definitely need views.



Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP:     Ramsgate
JID: matthew at               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the bind-users mailing list