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

[Kevin Darcy]

D. J. Bernstein wrote:

> Kevin Darcy writes:
> > First, you could define the forwarding mode as "forward first"
>
> No! That's a reliability disaster for internal domains. If there's a
> temporary problem reaching the internal server---if, for example, its
> network connection is briefly overloaded---then you will fall back to
> external servers.

Huh? Why on earth would you assume that? "Forward first" falls back to
*iterative* resolution. At this point it's *no*different* than if it had
reached the same point iteratively via a delegation chain. What does an
iterative resolver usually do when it has valid and complete delegation
information, but none of the nameservers for the domain it's asking about are
answering? Go and ask the root servers? Maybe your broken cache does that, but
the correct thing to do is return SERVFAIL.

> Those external servers will tell you that the domain
> doesn't exist. Your mail deliveries will bounce, instead of being retried
> properly.

No, SERVFAIL is a temporary, retryable error.

> > The other way to deal with this is to define the zone as "type
> > stub" instead of "type forward".
>
> I haven't seen any documentation on stubs. It appears, from the code,
> that you can't use stubs to directly configure forwarding targets; the
> targets are specified by NS records.

Yes, perhaps I should have added that caveat. Stub only works if the
NS records published in the apex zone contain the nameservers you want to use
for resolution. If you need to override those NS records, then stub won't
work, but any of the other zone types (master, slave or forward) will.

Remember, though, that we're talking about a scenario in which we want to
follow delegations. We presume that *those* are correct. So, what are the
chances that the delegations for all of the descendant zones are correct, but
the NS records at the apex itself are bogus? That seems like a pretty
pathological situation to me...

> Furthermore, BIND seems to blindly
> cache incorrect data within the internal domain from external servers.

I'm not sure what you're getting at here. Do you mean data from forwarded
queries? A properly-configured forwarding server won't be forwarding for any
name in an internal domain anyway. That's the whole point of setting
"forwarders { }" at the apex of each internal domain...

Or, did you mean that an improperly-configured stub zone could "leak" external
data into an internal domain? If that happens, it's a self-inflicted injury.
Neither BIND nor any DNS implementation knows inherently "internal" from
"external" -- it's all a matter of what data from which servers are used for
what purposes. Bad configuration can result in improper mixing of internal and
external data. This is not the fault of the implementation.

> > Your documentation only states that dnscache supports recursive fowarding
> > *globally*. BIND also supports it *selectively*
>
> My documentation explains the selection mechanism, and it then explains
> the recursion mechanism. I do not assume that readers are idiots.

The only mention you make of dnscache generating recursive queries in either
faq/cache.html or dnscache.html is in the description of what happens when one
sets up FORWARDONLY: "dnscache will send recursive queries to the external
cache for any information it doesn't have". A *single*, vague sentence
describing *all* of dnscache's recursive-forwarding capabilities. How
edifying.

It's one thing to not assume that readers are idiots. It's another to assume
that they can read your mind, or to expect them to grovel through code just to
get answers to basic configuration questions.


- Kevin