forwarding to a child zone is different!!

[Brian Wellington]

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