forwarding to a child zone is different!!

Badbanchi, Hossein HBadbanchi at Webasto.de
Wed Apr 25 13:00:35 UTC 2001


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

Maybe you are right.
What I say is that bind 9.1.1 doesn't enforce this (while it does enforce
exclusiveness of any other types of zones).
Within the scope of the same zone it accepts both a stub and a forward type
definition for the same domain, downloads the SOA, NS and associated A
records
from the masters specified in the stub zone definition, *but* then uses the
forwarded server's data to resolve names in that zone!

> Or did you mean a stub
> zone that is a _subdomain_ of a selectively-forwarded "zone", or
_vice_versa_?

As a matter of fact in the previous disscusion I did mean the "_vice_versa"
configuration. That is when we have a stub zone definition for some child of
ours, and at the same time a forward zone definition for a child of the
previously
defined stub type child.

> If so, this is inconsistent with the delegation
> requirement of selective forwarding.

I gather from this last sentence that:
	"selective forwarding *requires* delegation."
(sorry I haven't read the fourth eddition of DNS and BIND yet, maybe this is
explicitly written there).

I have only two further questions which might sound rediculous to you (at
least
the first one sounds extremely rediculous to me!).
If "A" *PROPERLY* delegates some sub-zone of his zone to "B" (by *PROPERLY*
I mean via stub type zone definition or via explicit NS and associated
A records or a combination of both, eventhough if we use both the explicitly
specified records are ignored), and if "B" *PROPERLY* delegates some
sub-zone of his zone to "C", does this delegation of "B" to "C"
to be %100 correct, require that the it (i.e. delegation of "B" to "C")
should be reflected in "A"'s zone files?

But now the serious question.
If the answer to the above question is negative, then is it legitimate
for "A" to define a forward zone in his configuration files for 
the zone delegated to "C" (i.e. "C.B.A"), or are there some pre-conditions
which need to be met before such a forward type zone definition can be
legitimately done in "A"'s site (except the above mentioned two
*PROPER* delegations I mean)?

Excuse me for sending this email directly to you, but I have already got
some offending answers from other list members for a similar question.

Hossein





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



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





More information about the bind-users mailing list