forwarders are unreachable -> lookup fails?

Kevin Darcy kcd at
Thu Mar 22 00:20:27 UTC 2001

Brad Knowles wrote:

> At 5:33 PM +0000 3/21/01, Jim Reid wrote:
> >  Another moral is don't forward if at all possible. Forwarding is evil.
> >  Unfortunately it is a necessary evil in some circumstances. Using
> >  forwarding to build up a huge cache on one central name server is not
> >  a valid justification for forwarding in my opinion.
>         Really?  I wasn't aware that you felt this way.
>         In my experience, forwarding plus caching has been the only way I
> could guarantee a relatively consistent "one world" view of the DNS
> across all the caching/recursive nameservers I've used, and has been
> the only way I could find that would off-load enough unnecessary work
> so that the central caching nameservers would be able to survive the
> pounding that they would otherwise have taken.
>         If you don't mind, I'd be extremely interested to learn as much
> as I could from you as to why you feel that this strategy is a bad
> idea.

As we discussed last week, the "one-world consistency" justification is quite
debatable, at least in the context of SMTP. Maybe a stronger argument could be
made for "one-world consistency" in the case of more interactive protocols e.g.
HTTP, since you don't want DNS inconsistencies to interfere with, e.g. navigating
a website. Proxies complicate that argument though.

As for the performance argument for centralized caching, I still don't see how
concentrating a ton of name-resolution work on just a relatively-small set of
servers, and introducing extra forwarding overhead in the process, is going to
produce any net performance gains, versus spreading the workload over a larger
number of autonomously-resolving machines. That is, unless one has a very unusual
usage profile, e.g. lots of cyclic query patterns, where the interval of the cycle
is approximately equal to the TTLs of the records being queried (in that case,
centralized caching might be a win, because the first query in each cycle gets the
answer into the cache so that the other queries don't need to go over the WAN to
get it).

The most compelling argument I can think of for centralized caching is the "civic
duty" argument, i.e. reduce the load on the root and TLD servers by limiting the
numbers of servers querying them. But even that argument tends to lose its potency
as new TLDs are rolled out, or existing TLDs (e.g. .tv, .ws, .to etc.) are
"repurposed" to serve generic uses...

- Kevin

More information about the bind-users mailing list