confused - can you clear the mud? - ignorant newbie

Tue Nov 27 23:14:01 UTC 2001

Well, the first thing to get clear on is that there is a distinction between a
"domain" (or "subdomain"), on the one hand, and a "zone" (or "subzone"), on the
other. All zones -- except the root zone -- are subdomains of some parent
domain, but not all (sub)domains are zones. If you have registered
orcsoftware.com, for instance, then this is both a subdomain and a subzone of
the "com" zone (since that's the way the "com" registrars do things). The names
london.orcsoftware.com and www.london.orcsoftware.com, if they exist, are
subdomains of that domain, but it is up to you whether or not to split them off
as subzones of the orcsoftware.com zone/domain.

If you just want a *subdomain*, but not a subzone, then you just add the
desired records to the parent zone file. E.g. in the orcsoftware.com zone file,
you could add the entries:

london              a    12.23.34.45
www.london    a    23.34.45.56

This would create a subdomain london.orcsoftware.com and a subdomain of that
called www.london.orcsoftware.com. Each of those names would then own an A
record. But all of that data would be considered part of the orcsoftware.com
zone. Note that in the example it is entirely optional to have an A record for
london.orcsoftware.com; if there were no london.orcsoftware.com A record,  then
you could still create a www.london.orcsoftware.com A record; in that case,
london.orcsoftware.com would simply be a name that owned no records. (The
reason I bring this up is that sometimes nameservers will respond differently
for "empty" names, like the london.orcsoftware.com name which is just a
placeholder between the orcsoftware.com domain and the
www.london.orcsoftware.com name, than they will for names which simply don't
exist, e.g. foobar.orcsoftware.com).

Splitting off a subzone, on the other hand, is done through "delegation". The
concept of delegation, as the name suggests, is to give control over part of
the namespace to a set of nameservers (usually but not always a *different* set
of nameservers than those which are responsible for the parent zone).
Delegation is hierarchical, so when you delegate a subdomain *as* a subzone,
you only delegate at that point in the hierarchy and then those other
nameservers take control over everything underneath. (Actually, there is a
special-case exception to the rule above, known as "glue records", but I won't
get into that right now).

So, if you wanted "london.orcsoftware.com" to be a subzone rather than just a
subdomain of orcsoftware.com, you could delegate like this:

london    ns    ns-london1.orcsoftware.com.
               ns    ns-london2.orcsoftware.com.

This would give control of the "london.orcsoftware.com" hierarchy, as a
(sub)zone, to the ns-london1 and ns-london2 nameservers. Everything underneath
that point would then be under the control of those nameservers, including,
e.g. www.london.orcsoftware.com.

So, why would one delegate subzones as opposed to just creating subdomain
entries in the parent zone? There are 2 main reasons for delegation:

1) Separation of maintenance responsibility. Delegating the subzone to another
set of servers allows the administrators of those servers to maintain the
entries in them, as opposed to requiring that all of the local administrators
be given access to the parent zone, e.g. to the orcsoftware.com zone. This
often has organizational/political/logistical benefits, because things can get
rather uncomfortable/dangerous when everyone and their brother is changing the
same zone data.

2) Zone-transfer granularity. As you are probably already aware, DNS data can
be replicated from masters to slaves using the standards-defined protocol AXFR.
AXFR replication occurs on a zone-by-zone basis. When using AXFR for
replication, if every bit of your organization's DNS data is kept in a single
zone, then every time the zone changes, the entire thing needs to be replicated
to all of the slaves. This can be very resource-intensive. For this reason, it
is historically common to break down large namespace hierarchies into subzones
in order to optimize zone-transfer volume (a common strategy is to try and
segregate the frequently-changing data into their own zone(s)), even if the
delegations are being made to exactly the same set of servers at all points in
the delegation tree. IXFR is an improved version of AXFR -- the "I" stands for
"incremental", which means exactly what it says -- and changes this equation
somewhat, however support for IXFR is/was still evolving as of BIND 8, so it
hasn't seen wide deployment yet. Besides, old subzone-delegation habits are
hard to break :-)

- Kevin

Darren Robertson wrote:

> Hi.
> I hope that you can help to explain things to me.
>
> I have been reading the first few chapters of the DNS & BIND (O'Reilly) book
> on and off for the last few weeks in an attempt to understand how to go
> about setting up DNS at our site and all I seem to do is get more and more
> confused.
>
> Initially I thought that this would be easy as most of the hard work had
> been done but  I can't seem to get out of the starting blocks.
>
> Here is the situation.
>
> About a year ago the company that I work for registered a domain:
> orcsoftware.com which all satellite offices were (are) part of. Recently
> they decided that it would be a good idea if there was a sub domain of
> orcsoftware.com for each satellite office, in my case
> London.orcsoftware.com.
>
> I thought that as I already had a sun box that could do an nslookup that I
> wouldn't have to do much more to get this set up as a DNS server......
>
> I have been able to download BIND 9.1.3 and believe that I have this
> installed correctly - there were no errors reported during the ./configure
> or make steps of the installation.
>
> But no matter how many times I try to make sense of the next steps I just
> can't - I've tried taking some time away from the project hoping that coming
> back fresh might help but it hasn't can anyone try explaining things so that
> everything may click into pace?
>
> I'm sorry for asking what is probably a simple question but I just cant get
> my head round this at the moment.
>
> Apologies and thanks in advance.
>
> D.
> --
> __________
> Darren Robertson
> Technical Support
> ORC Software
> __________
> Tel: +44 (0)20 7942 0999
> Fax: +44 (0)20 7942 0940
> www.orcsoftware.com
> __________
> Orc Software e-mail Disclaimer.
> If you have received this e-mail in error or wish to read our e-mail
> disclaimer statement and monitoring policy, please refer to
> http://www.orcsoftware.com/disclaimer or contact the sender.
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.298 / Virus Database: 161 - Release Date: 13/11/2001