forwarding to a child zone is different!!

[Badbanchi, Hossein]

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

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!

Hossein.


-----Original Message-----
From: Brian Wellington [mailto:Brian.Wellington at nominum.com]
Sent: Tuesday, April 24, 2001 05:12
To: Kevin Darcy
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, Kevin Darcy wrote:

> I disagree with the design decision that ISC has apparently made here. The
> ability to forward queries for a particular domain to some particular set
of
> nameservers should not IMO depend on whether that domain happens to be
delegated,
> or, worse yet, on whether the forwarding nameserver *knows* whether the
domain is
> delegated or not because of pure happenstance it is also authoritative for
an
> ancestor zone. Two machines sit side by side, each with a defined zone of
type
> "forward" for foo.example.com, an undelegated domain; this forwarding
works for
> one nameserver but not the other, because one of them happens to also be
> authoritative for some *other* zone (example.com). To me, this violates
the
> Principle of Least Surprise. Forwarding is an *explicit* directive from
the
> administrator, and often zones of "type forward" are created specifically
> *because* the zones are undelegated and that is the only way names in the
domain
> can be resolved. The presence or absence of delegations for a domain, in
turn,
> are often driven by local policy (e.g. security policy) which I don't
think
> should be dictated by a DNS implementation.

This makes perfect sense, and follows the resolver algorithm specified in
RFC 1034.  Relevant parts quoted and annotated:

   2. Search the available zones for the zone which is the nearest
      ancestor to QNAME.  If such a zone is found, go to step 3,
      otherwise step 4.

If a child zone is not delegated properly, records under the child are in
the parent zone.  No amount of configuration changes the concept of
delegation, which is a property of the data.

   3. Start matching down, label by label, in the zone.  The
      matching process can terminate several ways:

         a. If the whole of QNAME is matched, we have found the
            node.

This doesn't happen, since the name doesn't exist.

         b. If a match would take us out of the authoritative data,
            we have a referral.  This happens when we encounter a
            node with NS RRs marking cuts along the bottom of a
            zone.

This would happen with a correctly configured delegation.

         c. If at some label, a match is impossible (i.e., the
            corresponding label does not exist), look to see if a
            the "*" label exists.

            If the "*" label does not exist, check whether the name
            we are looking for is the original QNAME in the query
            or a name we have followed due to a CNAME.  If the name
            is original, set an authoritative name error in the
            response and exit.  Otherwise just exit.

This is what happens.

> I also find it architecturally inconsistent to impose a new
> requirement that zones of type "forward" be delegated, if the same
> requirement is not imposed on zones of type "stub". The two mechanisms
> are logically similar, inasmuch as they are both ways to direct
> queries matching certain criteria to a specific set of nameservers,
> instead of following the normal delegation chain. That one works in
> the absence of zone delegation and the other does not is, as I said,
> inconsistent.

DNS doesn't have the concept of forward zones.  Forward zones are an
abomination of bind 8.  The point of them is domain-specific forwarding in
cases when the normal resolver algorithm is insufficient or will not work.
When delegation records are omitted and the data is part of an
authoritative zone, the resolver is never used.

> At the very least, since forwarding of undelegated domains/zones is
> something that worked in BIND 8 and by design (apparently) no longer
> works, this should be clearly documented in doc/misc/migration; the
> specific impact on forwarding is not something that can be clearly
> inferred from "No Information Leakage between Zones".

Maybe.  But don't forget that the whole reason this came up was a
configuration error.

Brian