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

[Kevin Darcy]

D. J. Bernstein wrote:

> Kevin Darcy writes:
> > use that same set of servers for foo.example.com and all subzones
> > thereof, *even*though*the*delegations*point*elsewhere*,
>
> It makes no sense to ignore the delegations. Those servers _do not have
> the information_.

Maybe they do, maybe they don't. Maybe the "forwarders" are actually
"stealth slaves" for the zones in question. Heck, maybe the admin's whole
reason for "hardwiring" those servers is to increase performance, because
the stealth slaves are actually *closer* than any of the published
nameservers for the zone in question (before you dismiss this as
far-fetched, allow me to inform you that I make extensive use of stealth
slaves here at Chrysler; in fact for any given subzone of chrysler.com,
I have more stealth slaves than published nameservers). There are lots of
reasons to override delegations, and oftentimes one might wish to override
a whole *hierarchy* rather than just one particular zone. I'll take your
protestations as an admission that this is painful to do with djbdns.

> You have to contact the proper servers. This is what
> djbdns does automatically. BIND has no comparable mechanism.

_Au_contraire_. 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*. I just tested this
principle with some of our internal zones (I set up chrysler.com as "type
forward" on my workstation, pointing to a caching-only box and then
observed that named forwarded a query for a name in a subzone of
chrysler.com to that machine, totally bypassing the delegations).

Like I said in my previous post, BIND defaults to forwarding hierarchies,
djbdns defaults to forwarding only individual zones. Each package therefore
has its best-case scenarios and its worst-case scenarios, in terms of
ease-of-configuration. Your table is slanted because it picks BIND's
worst-case scenario and deftly avoids showing the worst-case scenario of
djbdns.

> A _cache_ will contact the proper servers on your behalf, if you have
> authorization to use that cache. The point of BIND's forwarding, and
> djbdns's FORWARDONLY, is to funnel requests through an external cache.
> But a _server_ has no reason to accept recursive queries.

Red herring. I wasn't talking about "servers". I was comparing dnscache and
the resolver component of named. Authoritative nameservers have nothing to
do with this.

> > I can't imagine anyone who cares about the ease of
> > installing/maintaining/cloning their DNS setup running with *both*
> > packages simultaneously, except possibly as a temporary migration
> > step. If they do, they're insane.
>
> It's common for people to install djbdns and switch their caching to
> dnscache, following strategy 2 in http://cr.yp.to/djbdns/frombind.html,
> before they've even started to consider whether to switch their DNS
> service to tinydns. This is a very easy way to deal with a BIND cache
> running out of memory, for example.

As I said, that's a disaster in terms of installing, maintaining and/or
cloning one's DNS setup.

> > My point is, though, whether it's 3Kb or 3Mb, waste is waste.
>
> Get a grip. Resource consumption is a matter of economics, not religion.
> Spending 3MB is 1024 times more important than spending 3KB.

Fine. Do you admit that duplicating the same code in both dnscache and
axfrdns is wasteful, albeit *minimally* wasteful? I'm not looking for a
"religious conversion" here, just an honest admission.


- Kevin