forwarding to a child zone is different!!

[Kevin Darcy]

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.

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.

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


- Kevin

Brian Wellington wrote:

> On Mon, 23 Apr 2001, Badbanchi, Hossein wrote:
>
> > I agree with you that without the NS records I am delegating incorrectly.
> > But why the server can live without these necessary NS records for
> > other types of zones.
>
> Just because it works doesn't mean it's not broken.  When you incorrectly
> configure the server, you get undefined behavior.
>
> > Here is a paragraph of documentation comming with bind 9.1.1:
> > BIND 9 stores the authoritative data for each zone in a separate data
> > structure, as recommended in RFC1035 and as required by DNSSEC and
> > IXFR.  When a BIND 9 server is authoritative for both a child zone and
> > its parent, it will have two distinct sets of NS records at the
> > delegation point: the authoritative NS records at the child's apex,
> > and a set of glue NS records in the parent.
> >
> > So when "BIND 9 stores the authoritative data for each zone in a separate
> > data
> > structure", then why it does not already know that the zone
> > "forward.mydomain.com"
> > is a sepatrate zone from "mydomain.com", while even WITHOUT explicit NS
> > records
> > for "stub.mydomain.com" and "slave.mydomain.com" in the "separate data
> > structure"
> > kept for "mydomain.com", bind knows that these two domains are delegated.
> > Please note that the NS record dowloaded from "stub.mydomain.com" are not
> > mixed in the zone information kept for "mydomain.com".
> > And if we omit the NS records for these two delegated zones from the zone
> > file
> > of "mydomain.com", still everything works fine. (Note that the the same
> > bind server is authorative for the parent and child zones.)
> > Only for the zone "forward.mydomain.com" the glue NS record is absolutely
> > necessary.
>
> Type forward zones are not zones, are not authoritative, and are not in
> the zone database.  Therefore the paragraph you quoted doesn't apply.
>
> What the server does is find the zone that contains the data and answer
> the query.  If the data is not in an authoritative zone, it uses the
> forwarders.  Since your child zone was not delegated, the child data is in
> the parent zone.
>
> > I mean in this scenario (when the same server is authorative for parent and
> > childs), if it can distinguish that "stub.mydomain.com" is delegated WITHOUT
> > the proper NS records for it in it`s zone information structure (I don`t say
> > named.conf file any more), then it should also be able to recognize that
> > "forward.mydomain.com" is not part of "mydomain.com" zone and has it`s own
> > zone and should send names in this zone to the forwarders specified for it.
>
> No, it shouldn't.  DNS has a well-defined way of delegating zones, and
> you're not using it.
>
> > According to the above paragraph the glue NS records are necessary in the
> > parent
> > zone. But what I don't understand is that why without them the server can
> > resolve names in "slave" and "stub" zones but not names in "forward" zone.
>
> Because in those cases, the server doesn't need to look in the parent
> zone.  It finds the best matching authoritative zone in the zone database
> (which is the child zone) and answers from there.
>
> Brian