forwarding to a child zone is different!!

[Badbanchi, Hossein]

I didn't know that "Type forward zones are not zones,
are not in the zone database."

Thanks for the info.

Hossein

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


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

> 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.


Just because it works doesn't mean it's not broken.  When you incorrectly
configure the server, you get undefined behavior.

> 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.

Type forward zones are not zones, are not authoritative, and are not in
the zone database.  Therefore the paragraph you quoted doesn't apply.

What the server does is find the zone that contains the data and answer
the query.  If the data is not in an authoritative zone, it uses the
forwarders.  Since your child zone was not delegated, the child data is in
the parent zone.

> 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.

No, it shouldn't.  DNS has a well-defined way of delegating zones, and
you're not using 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.

Because in those cases, the server doesn't need to look in the parent
zone.  It finds the best matching authoritative zone in the zone database
(which is the child zone) and answers from there.

Brian