forwarding to a child zone is different!!

Badbanchi, Hossein HBadbanchi at Webasto.de
Mon Apr 23 20:50:20 UTC 2001


I agree with you that without the NS records I am delegating incorrectly.
But why the server can live without these necessary NS records for
other types of zones.

Please consider the following scenario.

named.conf:

zone "." {
	type hint;
	file "cache";
};
zone "mydomain.com" {
	type master;
	file "db.mydomain.com";
};
zone "forward.myomain.com" {
	type forward;
	forward only;
	forwarders { ip_addr_of_ns_of_forawrd_of_mydomain; };
};
zone "stub.mydomain.com" {
	type stub;
	file "db.stub.mydomain.com";
};
zone "slave.mydomain.com" {
	type slave;
	file "db.slave.mydomain.com";
};

db.mydomain.com:

$TTL 864000
$ORIGIN mydomain.com.
@	IN SOA  mydomain.com. hbadbanchi.mydomain.com. ( 1 3600 300 3600000
86400 )
@	IN NS  ns
ns	IN A   ip_addr_of_ns_of_mydomain
stub	IN NS  stub.mydomain.com.	<<< works even without this.
slave	IN NS  slave.mydomain.com.	<<< works even without this.
forward	IN NS  forward.mydomain.com.	<<< can't resolve names if this line
is omitted!!!

Here is a paragraph of documentation comming with bind 9.1.1:
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.

So when "BIND 9 stores the authoritative data for each zone in a separate
data
structure", then why it does not already know that the zone
"forward.mydomain.com"
is a sepatrate zone from "mydomain.com", while even WITHOUT explicit NS
records
for "stub.mydomain.com" and "slave.mydomain.com" in the "separate data
structure"
kept for "mydomain.com", bind knows that these two domains are delegated.
Please note that the NS record dowloaded from "stub.mydomain.com" are not
mixed in the zone information kept for "mydomain.com".
And if we omit the NS records for these two delegated zones from the zone
file
of "mydomain.com", still everything works fine. (Note that the the same
bind server is authorative for the parent and child zones.)
Only for the zone "forward.mydomain.com" the glue NS record is absolutely
necessary.

I mean in this scenario (when the same server is authorative for parent and
childs), if it can distinguish that "stub.mydomain.com" is delegated WITHOUT
the proper NS records for it in it`s zone information structure (I don`t say
named.conf file any more), then it should also be able to recognize that
"forward.mydomain.com" is not part of "mydomain.com" zone and has it`s own
zone and should send names in this zone to the forwarders specified for it.

According to the above paragraph the glue NS records are necessary in the
parent
zone. But what I don't understand is that why without them the server can
resolve names in "slave" and "stub" zones but not names in "forward" zone.

hbadbanchi at webasto.de



-----Original Message-----
From: Brian Wellington [mailto:Brian.Wellington at nominum.com]
Sent: Monday, April 23, 2001 20:37
To: Badbanchi, Hossein
Cc: 'bind9-users at isc.org'
Subject: Re: forwarding to a child zone is different!!


On Mon, 23 Apr 2001, Badbanchi, Hossein wrote:

> It seems that forwarding to a child zone from within a parent zone doesn't
> work unless there are glue(!?) NS records in the zone file of the parent
> for the nameserver of the child zone explicitly telling "bind" that this
> child has been delegated.
> (glue(!?) A records are not necessary!)

This seems like correct behavior.  Without the NS records in the parent,
there is no child zone.  The server determines that the query can be
answered from authoritative data and answers.

> It seems that "bind" will not try to lookup "child.thisdomain.com" zone
> when he himself is authorative for "thisdomain.com", AND there are no NS
> records specifying that "child.thisdomain.com" has been delegated.

This is correct.

> Is this the way it is supposed to be?
> While we have explicitely specified "ip_addr_of_ns_of_child_of_thisdomain"
> in the zone statement, why there should additionally be an NS record for
> the child zone in the parent zone in this case that we have a zone
> statement for the child?

There's a difference between DNS and the named.conf file.  DNS requires
that zones be properly delegated.

> Interestingly if all the nameservers for "anotherdomain.com" are down
> still names in "child.anotherdomain.com" can be resolved, since the
> ip_addr of nameserver of "child.anotherdomain.com" which is specified in
> the zone statement will be contacted directly.
>
> And ofcourse the names in "child.thisdomain.com" can be resolved from any
> other domain (execpt the parent) even if there are no NS records in
> "thisdomain.com" for> this child,
> or even if all the nameservers of "thisdomain.com" are down.
> You see.
> My problem is that why the parent himself can not resolve names which
others
> can independent of this parent.
>
> Is this an implementation decision or is it part of an RFC?

By not adding an NS record in the parent, you're delegating incorrectly.
It's not surprising that it doesn't work.

Brian


More information about the bind-users mailing list