forwarding to a child zone is different!!

[Badbanchi, Hossein]

Hi.

> I think selective forwarding is more consistent (with the behavior
> of stub zones and global forwarding) and easier to administer
> when it is divorced from the delegation hierarchy.

Would you please direct me to a document where I can find an explicit
rule telling that forwarding must be bound to delegation.

I couldn't find anything in this regard in DNS and BIND third edition.

I still think that selective forwarding does NOT follow the delegation
hierarchy when it comes to stub zones. Or may be stub zones do not fall
under the category of "Authoritative data".

Thanks in advance.

Hossein


-----Original Message-----
From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
Sent: Tuesday, April 24, 2001 21:22
To: 'bind-users at isc.org'
Cc: 'bind9-users at isc.org'
Subject: Re: forwarding to a child zone is different!!



Brian Wellington wrote:

> 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 understand the RFC algorithm, but surely forwarding is an explicit
*override* of
that algorithm, so why keep the vestigial delegation requirement? I think
selective
forwarding is more consistent (with the behavior of stub zones and global
forwarding) and easier to administer when it is divorced from the delegation
hierarchy. Maybe selective forwarding shouldn't even be defined in a zone
{ } statement, since, as you've pointed out, it really has nothing to do
with zones.
The forwarding mechanism should IMO kick in whenever a queried name
(assuming the
answer isn't in cache) matches a particular part of the namespace. Whether
or not that
part of the namespace happens to be delegated or not seems to me to be
beside the
point.

Now, it occurs to me that selective forwarding has probably *always* worked
this way,
since it was introduced _circa_ BIND 8.2. So this is not, as I thought, a
BIND 8
versus BIND 9 issue. I haven't used selective forwarding much, and just
happened to
notice this quirk for the first time recently when configuring a BIND 9
nameserver for
selective forwarding. So please ignore my comments about documenting this in
doc/misc/migration; obviously it's not a migration issue if BIND 8 and BIND
9 behave
the same way. It appears my objection is a little tardy :-)


- Kevin