> Let us assume that a name server, ns1.example.com, is authoritative
> over the example.com domain and all subdomains of example.com.
> Perhaps aaa.example.com is a subdomain of example.com. We could
> configure BIND on ns1.example.com by adding the following directives
> to its named.conf file:

zone "example.com" {
> type master;
> file "/etc/bind/db.example.com";
> };
> zone "aaa.example.com" {
> type master;
> file "/etc/bind/db.aaa.example.com";
> };
> Each of the files within the /etc/bind directory would then contain
> the zone definitions, including any DNS resource records (RR's) that
> we wish to place in the zone.
> Let me first say that while example.com and aaa.example.com have
> separate directives in the named.conf file, and contain zone
> definitions in separate files, I believe that they are, in fact,
> members of the same zone.

No, they are two zones.

example.com could be served by NS1 and NS2.
aaa.example.com could be served by NS1 and NS3.

Just because NS1 serves both zones it doesn't mean they
are one zone.

> I have concluded this due to my
> understanding that a "zone" is the following: "The largest contiguous
> subtree within the domain tree for which a name server is
> authoritative." (Does anyone disagree with that definition of a
> "zone"?)

A zone starts at the SOA record and extends downwards (top
is the root) until a delegating set of NS records is found.
These should be a *copy* of the NS records from the child
zone. The top of the child zone will have a SOA record and
NS records.

> If my zone definition is correct, then the use of the term "subzone"
> in reference to aaa.example.com's relationship to example.com is not
> accurate, but is a convenient term to use given the BIND configuration
> presented above.

Parent/child better describes the relationship. example.com
is the parent, aaa.example.com is the child.

> Returning to my example, perhaps we wish to specify name server (NS)
> records for the aaa.example.com "subzone". I have found that
> apparently BIND does not honor the placement of such a record in the
> example.com zone file (/etc/bind/db.example.com in our case) like the
> following:
> aaa.example.com. NS ns2.example.com
> If I place that record in /etc/bind/db.example.com on ns1.example.com,
> ns1.example.com will not return the NS record for ns2.example.com as a
> result when queried.

You just have to issue the right query.

"dig axfr example.com" will show the delegating set of NS

> I lack understanding as to why this behavior is exhibited. Ought it
> not be within the capabilities of a "zone" to specify the name servers
> of its "subzones" ("zone" and "subzone" used in the BIND sense)? Can
> anyone confirm that this is expected behavior? (Or at least provide
> justification as to why it was implemented this way?)

You should changing the NS records in *both* zones. When
named serves both the parent and child zones the NS records
returned come from the child zone when answering NS queries.
Remember the parent zone is supposed to contain a *copy* of
the childs NS records.

This is what RFC 1034 has to say:

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone. The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.


> Thanks,
> Eric

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org