Users Want *Seamless* Solutions, Not Patchwork (was Re: Users want solutions, not buzzwords)

Kevin Darcy kcd at daimlerchrysler.com
Fri Aug 3 00:03:45 UTC 2001


D. J. Bernstein wrote:

> Kevin Darcy writes:
> > If example.com is set up as a "type forward" in BIND, then
> > in the absence of an explicit zone configuration for foo.example.com,
> > that name will be forwarded as well, to the same set of forwarders,
> > *even*if*foo.example.com*is*delegated*to*other*servers*.
>
> Right. That's exactly the problem.

But it's not always a "problem". If you *want* to ignore these delegations,
then not only is it *not* a problem, it's actually a *feature*. And,
coincidentally, one that djbdns lacks.

Over the years, whenever some vendor or marketroid tells me that a certain
software behavior is "automatic", my conditioned reflex is to immediately
question "but what if you don't *want* that behavior? How easy is it to
turn off?". There's always a tradeoff between "automation" and flexibility.
If you want truly "automatic", go buy a Microsoft product or an appliance.
Both djbdns and BIND would, I hope, offer more flexibility than that.

> BIND supports recursive forwarding
> (i.e., forwarding to caches); it doesn't support iterative forwarding
> (i.e., forwarding to servers).

> The difference is obvious when the forwarding target returns a referral.
> BIND simply chokes.

It only chokes if it's *configured* to choke in that situation. See below.

> The only workaround is to manually forward the child
> zone, exactly as shown in http://cr.yp.to/djbdns/blurb/easeofuse.html.

No, that's *not* the only workaround. BIND can deal with this in a couple
of other, easier-to-configure ways.

First, you could define the forwarding mode as "forward first" (the default
mode, although I personally disagree with that default) instead of "forward
only". "Forward only" tells named "choke if forwarding fails to produce a
definitive answer". If that's what you *want*, then that's how you
configure your forwarding mode. "Choke=yes". But if "forward first" is
configured, then when the forwarding "fails", named will fall back to
iterative querying, and since it just got a referral for the child zone, it
has enough information to go to that zone's nameservers directly and get
the definitive answer.

The other way to deal with this is to define the zone as "type
stub" instead of "type forward". (Note, however, that if forwarding is
enabled at a higher level of the hierarchy, you'll need a "forwarders
{ }" in the stub definition to selectively disable it for the hierarchy in
question).

The drawback of the first method is that it always generates a query to the
forwarders for anything in the hierarchy in question (assuming it doesn't
have the answer cached, of course), even if it has cached referral
information for the relevant descendant zone which could allow it to bypass
that step.

The drawback of the second method is that it generates a small amount of
stub-replication overhead, the frequency of which is determined by the
REFRESH setting on the zone in question. In return for this small
network-traffic expenditure, however, one gets some added robustness for
the zone.

But, we weren't discussing efficiency or robustness, were we? We were
discussing "ease of use". The fact that these BIND techniques may generate
some excess network traffic is irrelevant to the ease of configuring them.
In both cases, only a *single* zone definition is required for the whole
hierarchy. *This* is what you should be reflecting in your "ease of
use" table, since if "ease of use" is the yardstick, a stub zone or
"forward first" is the best way to configure BIND in this situation.

> In contrast, djbdns supports iterative forwarding, so it handles this
> situation automatically. djbdns _also_ supports recursive forwarding;
> your ``worst-case scenarios'' rhetoric ignores this fact.

Your documentation only states that dnscache supports recursive fowarding
*globally*. BIND also supports it *selectively* -- in fact, in BIND terms,
global recursive forwarding is really nothing more than the special case of
forwarding the root zone. At the same time, as discussed above, BIND can
deal -- albeit inefficiently -- with so-called "iterative
forwarding" scenarios, *without* requiring explicit zone definitions for
every zone involved. Bottom line: BIND can apparently do more things in the
forwarding/iteration context, when limited to a single configuration
element -- i.e. a zone definition -- than djbdns can do with a single
configuration element -- i.e. a file under "root/servers". Being able to
accomplish a wider range of tasks with an equivalent amount of
configuration: I'd call that superior ease of use.

Of course, I can only state this tentatively, since you _still_ haven't
documented/explained the interaction between your global and your selective
forwarding mechanisms. Your evasiveness on this point makes me wonder if
it's even uglier than I surmise...

> > Do you admit that duplicating the same code in both dnscache and
> > axfrdns is wasteful, albeit *minimally* wasteful?
>
> No. The code is reused for good reasons. There are two copies of the
> compiled code on disk, but you would have to be a fool to worry about
> this; there are much larger consumers of your resources. ``Premature
> optimization is the root of all evil.''

Translation: no matter how hard you press the point, I'll never admit my
wastefulness.


- Kevin





More information about the bind-users mailing list