DNS reverse zone delgation work in BIND8 but not BIND9

nixlayman · 04-01-2012, 08:13 PM

I found that DNS reverse zone delgation is not working in BIND9.x but working perfectly OK in BIND8.x with the same setup.

I am getting 'Non-existent host/domain' error when querying (for eg)
nslookup -type=any 112.35.10.in-addr.arpa
* localhost can't find 112.35.10.in-addr.arpa:Non-existent host/domain
--------------------
Here are my configuration files setup.
Anyone know what are the changes in BIND9... ??
(actually this happened on an Tru64 unix server)

./named.conf
_______________________________________
| . .
|zone "35.10.in-addr.arpa" {
| type master;
| file "zone/35.10.in-addr.arpa.data";
|};
| . .

./zone/35.10.in-addr.arpa.data
____________________________________________
|$TTL 300
|@ IN SOA nsi1.testchem.org. dnsadm.testchem.org. (
| 2012032600 ; serial
| . .
| 1d ) ; min
| IN NS ns1.testchem.org.
| IN NS ns2.testchem.org.
| . .
|112 IN NS ns5.radiochem.org.
|112 IN NS ns5.radiochem.org.
| . .
|13.115 IN PTR uranium.radioactive.testchem.org.
|;---------------------------------------
|116 IN NS ns6.geochem.org.
|116 IN NS ns6.geochem.org.
|;---------------------------------------
| . .
| . .
|122 IN NS ns12.physicalchem.org.
|122 IN NS ns12.physicalchem.org.
|;--------------------------------------
| . .
|14.127 IN PTR boron.element.testchem.org.
|24.127 IN PTR carbon.element.testchem.org.
| . .
| . .

bathory · 04-03-2012, 03:26 PM

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