Separate zone files for each of the sub-domain

[Kevin Darcy]

I think you need to clarify exactly what you are trying to do here. If you
truly want a *delegation* of these subdomains, then there is really no way to
separate the exposure of the fact that a subdomain is delegated from the
ability to resolve names in the subdomain/subzone, i.e. if you want
foo.bar.domain.com to be resolvable, then there is really no way to hide the
bar.domain.com delegation. That is to say, there is no reasonable way for
your nameserver to distinguish queries that are made for the purpose of
resolving a name in a subzone from queries made solely to discover whether or
not a subzone exists.

Now, having said that, if you want to only expose the existence of these
subzones (and all of the names contained in those subzones) to
*certain* clients, and deny their existence to other clients, then we're
talking about "split DNS", where you present different versions of DNS
reality to different clients. But before I go off in gory detail about how to
implement that, I'd like to confirm that that's what you actually want.

Note: if all you want to do is prevent clients from doing a listing of your
zone, then you can restrict that via the "allow-transfer" option. But that
only stops them from doing a total listing. They can still query the
subdomains directly, and if you're delegating them and not using split DNS,
they will be able to confirm their existence.


- Kevin


Danie I. wrote:

> Hi Kevin,
> I wish to thank you very much for your very kind & descriptive
> response.
>
> I have been off for many days and got this email only last night.
>
> I am using  ns1.granitecanyon.com for my primary nameserver:
> @ SOA.....
> domain.com.  IN NS  ns1.granitecanyon.com
>                      IN NS ns2.granitecanyon.com
>                      IN NS ns1.secondary.com
>                      IN NS ns2.secondary.com
>
> 1) Please advise on how to delegate out subdomains by an
> example.
> 2) my requisite is:
>
> subdomains1.domain.com.  IN NS ns1.anotherDNS.com.
>                                          IN NS ns2.anotherDNS.com.
> subdomains2.domain.com.  IN NS ns1.anotherDNS.com.
>                                          IN NS ns2.anotherDNS.com.
> where ns1.anotherDNS.com would be authoritative for the
> subdomains.
>
> For the privacy reason, I do not want anybody quering for my
> domain.com could see all the names of the subdomains, that's
> why I wish to have separate zone files for each of subdomains.
>
> Best regards & wishes
>
> Danie.
>
> On 11 Jul 2001, at 18:35, Kevin Darcy wrote:
>
> >
> > Danie I. wrote:
> >
> > > Hi there,
> > > I shall appreciate for the help on follwing:
> > >
> > > At a name server,
> > > can we create separate zone files for each of
> > > the subdomains instead of entring in the main
> > > domain's zone.
> >
> > Your question is unclear, but either way I parse it, the answer is
> > "yes".
> >
> > If you want separate *zones* for those subdomains, then you can delegate
> > them out and put separate "zone" definitions in named.conf for them, in
> > which case obviously you can also store then in separate files. Each
> > zone needs its own SOA record and a set of NS records, in addition to
> > the delegations from the parent. Also, your slaves will need to know
> > about the new subzones if you want the same degree of redundancy for
> > them as you have for the parent zone.
> >
> > On the other hand, if you want to keep the subdomains in the *same*
> > zone, but you just want to store each one in a separate file, then use
> > $INCLUDE directives in the (main) zonefile. In this case, since
> > everything stays in the same zone, you wouldn't need the extra NS and
> > SOA records, and you wouldn't need additional "zone" definitions in
> > named.conf on the master or the slaves.
> >
> > An important distinction here is between a "zone" and a "zonefile".
> > Through the $INCLUDE mechanism, a single zone can be loaded from
> > multiple zonefiles. Conversely, some folks load multiple zones from the
> > _same_ zonefile (but let's not confuse matters). Another important
> > distinction is between "zones" and "domains". Every zone is a domain (or
> > subdomain), but not every domain/subdomain is a zone. It's possible to
> > store many subdomains, or even many levels of subdomains, in a single
> > zone. The main reasons to delegate off a subdomain into a separate zone
> > are to delegate control of it to some other organization, or just to
> > break up your namespace in order to reduce zone-transfer overhead. As
> > explained above, it is *not* necessary to delegate a subdomains as a
> > subzone, just so you can keep the data in a separate file.