forwarding to a child zone is different!!

[Badbanchi, Hossein]

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

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

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

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

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.

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

Thank you for your patiance.

Hossein.


-----Original Message-----
From: Brian Wellington [mailto:Brian.Wellington at nominum.com]
Sent: Tuesday, April 24, 2001 06:17
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:

> I should tell that the whole reason this came up was NOT a
> confoguration error.
> I am testing bind 9.1.1, and want to see how does it behave.
> I agree with Kevin that the behaviour of bind here is incosistant.
>
> If I have:
> named.conf:
> zone "child.stub.myomain.com" {
> 	type forward;
> 	forward only;
> 	forwarders { some_other_ip_addr; };
> };
> zone "stub.mydomain.com" {
> 	type stub;
> 	file "db.stub.mydomain.com";
> };
>
> db.mydomain.com:
> $ORIGIN mydomain.com.
> @	IN SOA  mydomain.com. ...
> @...
> stub	IN NS  stub.mydomain.com.
> ns.stub	IN 	A	some_ip_addr
> host.stub	IN	A	ip_addr1
> host.child.stub	IN	A	ip_adrr2
>
> db.stub.mydomain.com on the stub machine:
> $ORIGIN stub.mydomain.com.
> @	IN SOA  stub.mydomain.com. ...
> @...
> host	IN	A	ip_addr3
> host.child	IN	A	ip_adrr4
>
> db.child.stub.mydomain.com on child.stub machine:
> $ORIGIN child.stub.mydomain.com.
> @	IN SOA  child.stub.mydomain.com. ...
> @...
> host.child.stub	IN	A	ip_adrr5
>
> Now if I ask for "host.stub.mydomain.com." and
> "host.child.stub.mydomain.com.",
> for the first one I will get ip_addr3 (from stub zone).
> and for the second one I get ip_addr5 (from the forwarded zone).
> I do NOT get ip_addr4 for host.child (from the stub zone).

As I said before, forward zones are not zones.  Stub zones are zones (more
or less).  According to RFC 1034, the DNS standard, BIND 9 is doing the
right thing.  If you can find a standard that allows you to omit
delegation records, please point it out.

> I want to say that eventhough bind knows that child.stub is in the stub
zone
> and has all the information to try to resolve it from it's original place,
> but it follows the forwarding directive, but for a similar query where
> he himself has the data it doesn't follow the directive.
> And worse even if he doesn't happen to have the data, it does not try
> the forward directive, but simply return not found!

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.

Forwarding is a special type of recursion, and the server will not recurse
if the data is determined to be within an authoritative zone.

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 a configuration error, whether you admit it or not.  Omitting
delegation records and expecting there to be a delegation anyway doesn't
work, and will lead to undefined results.

Brian