forwarding to a child zone is different!!

[Kevin Darcy]

Badbanchi, Hossein wrote:

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

The delegation requirement only applies to selective (per-zone or per-domain)
forwarding, which was implemented after Third Edition was written, so I'm not
surprised that you couldn't find a reference.

Note, however, that whatever Cricket writes in his books are not binding (no
pun intended) on the BIND software. Forwarding is not a mechanism which is even
defined explicitly by the RFC's (although there are passing references to it in
some RFC's). So, technically, ISC can implement forwarding any way they wish.
I happen to disagree with some of the design choices made in the current
implementation, as apparently do you.

> I still think that selective forwarding does NOT follow the delegation
> hierarchy when it comes to stub zones.

I'm not sure what you mean here: a zone cannot be both "type stub" and "type
forward" at the same time. So stubs and selective forwarding mutually
exclusive, at least within the scope of a single zone. Or did you mean a stub
zone that is a _subdomain_ of a selectively-forwarded "zone", or _vice_versa_?

> Or may be stub zones do not fall
> under the category of "Authoritative data".

That is correct. Like selective forwarding, stub zones are just a way to force
the nameserver to use a particular set of nameservers to resolve names in a
particular part of the namespace. And, like selectively-forwarded "zones", stub
zones do not grant "authority", since the nameserver does not have a full copy
of the zone. Unlike selective forwarding, however, there is an implicit
requirement that a stub zone actually be a *zone*, i.e. that it have an SOA and
at least 1 NS record. But to my knowledge, there is no requirement that the
stub zone be delegated. If so, this is inconsistent with the delegation
requirement of selective forwarding.


- Kevin

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