forwarding to a child zone is different!!

[Brian Wellington]

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