BIND's Implementation of Zones/"Subzones"

[Eric]

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.  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"?)

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.

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.

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?)

Thanks,

Eric