Hi,
I guess this is a consequence of:
Quote:
6. No Information Leakage between Zones
BIND 9 stores the authoritative data for each zone in a separate data
structure, as recommended in RFC1035 and as required by DNSSEC and
IXFR. When a BIND 9 server is authoritative for both a child zone and
its parent, it will have two distinct sets of NS records at the
delegation point: the authoritative NS records at the child's apex,
and a set of glue NS records in the parent.
BIND 8 was unable to properly distinguish between these two sets of NS
records and would "leak" the child's NS records into the parent,
effectively causing the parent zone to be silently modified: responses
and zone transfers from the parent contained the child's NS records
rather than the glue configured into the parent (if any). In the case
of children of type "stub", this behaviour was documented as a feature,
allowing the glue NS records to be omitted from the parent
configuration.
Sites that were relying on this BIND 8 behaviour need to add any
omitted glue NS records, and any necessary glue A records, to the
parent zone.
Although stub zones can no longer be used as a mechanism for injecting
NS records into their parent zones, they are still useful as a way of
directing queries for a given domain to a particular set of name
servers.
(Quote from bind-9.8.1-P1/doc/misc/migration)
|
You should use $ORIGIN and create new zone files for the child zones in the authoritatives name server(s), e.g:
Code:
$TTL 300
@ IN SOA nsi1.testchem.org. dnsadm.testchem.org. (
2012032600 ; serial
. .
1d ) ; min
IN NS ns1.testchem.org.
IN NS ns2.testchem.org.
. .
$ORIGIN 112.35.10.in-addr.arpa.
IN NS ns5.radiochem.org.
IN NS ns5.radiochem.org.
$ORIGIN 116.35.10.in-addr.arpa.
IN NS ns6.geochem.org.
IN NS ns6.geochem.org.
...
Regards
