forwarding to a child zone is different!!

[Badbanchi, Hossein]

> Where's the NS record for child.stub.mydomain?  If it's a separate zone,
> it needs an NS set in the parent.

It is in the zone file of "stub.mydomain". I have not written it here
just because the NS record for "child.stub.mydomain" in the zone file
of "stub.mydomain" is never accessed in this scenario (when we have
forwarding directive for "child.stub.mydomain" in the named.conf file
of "mydomain", the Grandparent).
As a matter of fact the NS record for "child.stub" in the "stub.mydomain"
zone file on the stub machine again references to another machine which
has a different ip_addr (ie ip_addrd6) for "host.child.stub.mydomain".
All this have been created only to be able to see where the data
comes from without using trace.

> Since there's no delegation, it probably should
> be responding from the stub zone.

As I said above there is a delegation, and if it was used I could recognize
it.
This delegation is only used when first (after startup) "mydomain" tries
to retrive the NS records and the associated A records from the masters of
"stub.mydomain".
Of course it will also be used if I delete the forward zone from "mydomain".

I did more tests and now I can tell that the process is as follows:

1)The closest matching zone of type master, slave or stub containg
the domain is found.

2) If it is a master or slave zone, bind tries to resolve the name
from it's own data. If found then gives back the result, otherwise
"not found: 3(NXDOMAIN)" (answer from host command).

3) If the zone is of type stub, then if the record is included in the
A records retrived (at startup) from the master (and written to the
stub file on the parent machine), then the A record is returned.
This will be the case only if the queried record is one of the NS records
of the stub zone AND has been successfully downloaded from the master.
(My tests show that this is not always the case. At different times,
different number of records are retrived from the master and written to
the file.)
Of course this applies only for A records and NS records.

4) If the data is not included in the zone data retrived from the master,
then the closest matching zone of type forward containing the domain is
found
(it should be closer than the stub zone). If there is one and the forwarders
list is not empty, the name will be resolved (or not resolved) through the
forwarders, and the result returned.

5) If the forwarders list is empty or there is no forward zone closer than
the
stub zone to the name, then the nameservers retrived from the stub will be
asked (I do not know with recursion or not) and the result is returned.

6) If in step one no zones of type master, slave or stub were found, then
the closetst matching zone of type forward is found. If any, it will be used
to resolve and return the result. Otherwise "not found".

Of course this process is what I have gathered as a result of my tests.
During the tests I have restarted the daemon each time to make sure nothing
will be used from the cache.

In the end it seems that forward zones are less "zone" than master/slave
zones,
and stub zones are even lesser "zone" than forward zones, but when it comes
to the order of using them, then forward zones are used only after bind
is certain that the queried data is in a deleagted zone (through delegation
NS records in the zone itself, or via the presence of a stub zone).

I hope the BINDv9 Engineering group will try to tell us why the behaviour of
bind is different between stub and slave/master zones, when it comes to
forwarding!!


Hossein





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


On Tue, 24 Apr 2001, Badbanchi, Hossein wrote:

> > This is a configuration error, whether you admit it or not.
> This is not a cofiguration error. As you can see in my examples
> I have included all necessary glue records for delegation.
> The point is that I am working on a perl script to extract
> zone files for different parent/child zones from the same set of data.
> And I need to test what kind of combinations are regarded as ERROR by
> bind.

Where's the NS record for child.stub.mydomain?  If it's a separate zone,
it needs an NS set in the parent.

> > As I said before, forward zones are not zones.  Stub zones are zones
(more
> > or less).
>
> You are completely right when you say "(more or less)".
> If I change the stub zone in my examples to a primary or even a slave
> zone, then bind completley ignores the forwrding driective.
> But please note that it doesn't do this for a stub zone.
> I mean it follows the forwarding directive for a stub zone,
> but ignores it for a slave/primary zone.

It's possible there's a bug in stub zone processing.  I've never used stub
zones, so I don't know.  Since there's no delegation, it probably should
be responding from the stub zone.

> > Forwarding is a special type of recursion, and the server will not
recurse
> > if the data is determined to be within an authoritative zone.
>
> If a stub zone is somehow(!?) an authoritative zone then why does bind
> FOLLOW the forwarding directive for a data which belongs to it,
> while it ignores it for a slave or primary zone.

I honestly don't know.

> > Stub zone processing is not recursion.  If the data is determined to be
in
> > a stub zone, the server will use the stub zone data to determine the
> > answer.
>
> This is exactly what does NOT happen. The data IS in the stub zone, bind
has
> glue NS records for the stub zone, but it answers from the zone which
> it has forwarding info for.
> Please note my example once more.
> I have delibrately (to see where the answer comes from) put different
> ip_addrs
> for "host.child.stub.mydomain" in the two zones "child.stub.mydomain" and
> "stub.mydomain". And I get the address from the first zone (the one which
> has the forward directive).

Again, I'll defer to someone who understands stub zones better.

> Or maybe I don't understand what you mean by "If the data is determined to
> be in
> a stub zone". How does bind determine this.

There's a data structure containing all real zones (primary, secondary,
and stub).  The closest matching one is found.  The name is then looked up
in the data structure containing the closest matching zone.  If the lookup
does not indicate that the name is below a delegation point, that zone is
the ultimate source of information for the name.

> > You're missing the point again.  Read RFC 1034.  The closest matching
zone
> > is found.  A stub zone is a zone.  A forward zone is not.
>
> If this is true then the closest matching zone for
> "host.child.stub.mydomain"
> should be "stub.mydomain" not "child.stub.mydomain" (which is a forward
> (?)zone).
> But bind resolves the address of this machine from the latter (non)zone.
> Why?

You're right.  I don't know.  I agree that this behavior is inconsistent,
although I stand by my point that the original problems (which did not
involve stub zones) were the result of a configuration error.

Brian