Arguments for/against use of forwarders{}?

[Kevin Darcy]

Simon Waters wrote:

> Steve Snyder wrote:
> >
> > What are the relative merits of using or not using the forwarders option?
>
> I've been known on the list as a "pro-forwarder" - if we're
> going to get political *8)
>
> > My nameserver (BIND v9.1, running on Linux) provides name resolution for
> > the rest of my LAN.  This server in turn can resolve queries sent to it in
> > 1 of 2 ways: either by contacting the root name servers or by forwarding
> > the query to my ISP's nameservers.  For the long term (i.e. caching) which
> > is the better method?
>
> "My nameserver" singular - and the guys are worrying about
> the target(s!?) of forward directives being a single point
> of failure. I suggest you want two or more nameservers -
> otherwise you already have a single point of failure in your
> DNS forwarding or not.
>
> > I am not referring to a "forward first" or "forward only" choice, but to a
> > simple config like this:
>
> There are two primary reasons to consider forwarding;
>
> Security: We need only exchange DNS packets with specific
> DNS servers.

Please allow me to clarify what you mean by "exchange": with forwarding you
*send* DNS queries to specific DNS servers and receive *responses* to those
queries. To be sure, DNS packet "exchange"s with arbitrary boxes on the
Internet is a lot less risky when you're the one initiating the exchange.
Almost all of the recent exploits have been in the query-processing code rather
than in response-processing code. But this relative safety comes from being a
*consumer* rather than a *provider* of DNS services, and restricting the set of
servers which you query buys you next to no additional security on top of that.
You get much more bang-for-the-buck, security-wise, by separating recursive and
non-recursive functions and not letting anyone but your own clients query
*your* recursive servers. As for what servers your recursive servers query,
that's a much more secondary security consideration.

Moreover, consider that your forwarders are probably answering queries from
umpteen other clients, some or maybe even most of which you do not trust. Any
one of those other clients could have corrupted the forwarder's cache,
compromised the box, or whatever. Which do I trust more: my forwarder, or the
delegated servers for each zone I'm looking up? If the data is tainted at its
source, i.e. on an authoritative server, then I shouldn't trust it, period --
I'm certainly not going to rely on the forwarder to somehow "sanitize" it for
me. And using a forwarder just adds another step in the query chain which could
be exploited in terms of cache corruption or machine compromise. The more
machines a response has to pass through before it gets to me, the less I trust
the contents of that response. So it would seem that using a forwarder is
inherently *less* secure than getting the data directly.

> The idea being that this is an extra level of defence
> against attacks like the recent tsig problem in BIND, to
> attack my name servers you first need attack my ISP's name
> servers (Spoofing complicates this - but if your ISP is good
> this probably isn't a problem).

Again, your nameserver is essentially at no direct risk from query *responses*.
So the "security" argument for forwarding basically holds no water, IMO.

> Performance: DNS resolution via forwarders can be faster.

Yes, it *can* be. But it often *isn't*. Remember that forwarding introduces a
mandatory hop for every (non-cached) query, and associated latency. So you
already start out at a penalty when you forward. Now, sometimes the relative
hit ratios on the forwarders, versus the hit ratios on your own local caching
box, outweighs that penalty. Sometimes it doesn't. If your internal backbone
network is *way* faster than your Internet connection, and your forwarder farm
has *lots* of capacity, then this tilts things performance-wise towards
forwarding, but ultimately it's a crap shoot that depends on query patterns and
cache hit ratios. Read on.

> If, like me, your ISP supports 100,000's of dial customers
> using their DNS servers, and the machines still respond
> quickly, then you can safely assume that many requests will
> be met from the DNS servers cache.

If the name is a "popular" one, it'll tend to always be in cache regardless of
whether you're using forwarding or not. If the name is an unpopular one, it'll
tend to not be in cache and require delegation-chain-resolution, in which case
forwarding is a big *loser* since you're *adding* the forwarding overhead and
latency to the delegation-chain-resolution that needs to be done regardless. So
forwarding only really helps in the "middle band" of
somewhat-frequently-queried names. Sometimes that middle band is so small as to
be effectively non-existent. Even when the band exists, the performance
benefits that forwarding offers for that band may not be enough to offset the
penalties you pay on the lower-frequency ("unpopular") end. And even if you're
extremely fortunate and forwarding helps your *average* query latency, it may
still hurt your *worst*case* query latency, which, depending on your customers
and their requirements, may actually be a more important metric than the
average query latency (especially if they have applications with tiny,
non-configurable lookup timeouts). Lastly, there is the cost/benefit analysis.
Forwarders cost money, which might be more productively spent simply putting
more caching servers in place. It may be impressive to quote high queries/sec
numbers for your nicely-centralized forwarder farm, but is it a responsible way
to spend your company's money, compared to the lower-profile, less-glitzy, but
probably more effective approach of strategically placing inexpensive caching
servers throughout the enterprise? I guess the perception of performance is
sometimes more important that the reality. It's easier to measure queries/sec
for a forwarder farm than it is to measure actual query latency on desktop
clients throughout the enterprise. Easier numbers beat out better numbers, it
appears.

(Note that when I say "popular" or "unpopular", this is an elastic term which
depends, among other things, on the TTL setting of the record(s) in question.
A name may be "unpopular", in this specialized context, even if it is queried
every 5 minutes on average, if its TTL is set to only 20 seconds. Conversely, a
name may be "popular", even if it is only queried once an hour, on average, if
its TTL is set to a day. It all comes down to cache hit ratios -- I'm basically
using "popular" and "unpopular" to express different value ranges for that
parameter).

> If you want "performance" you "forward first", so as to
> improve reliability.

Hmmm.... Doesn't that negate your "security" argument utterly? With "forward
first", the potential exists for your nameserver to talk to an indefinite
number of arbitrary servers on the Internet. Or are you saying that
forwarding-for-performance forces one to choose between security (forward
only) and reliability (forward first)? That's a hell of a choice (and maybe
even a non-existent one, since Denial of Service, which unreliability invites,
is generally considered a "security" matter these days).

Note that I haven't even mentioned the unmaintainability of forwarding until
now. Unmaintainability is *not* my main objection to forwarding. I dislike it
mostly on purely technical grounds. The fact that forwarding is easy for novice
admins to do badly or completely screw up, is just simply Yet Another Reason to
avoid it, in my opinion. But I still wouldn't use it when given the choice,
even if it were perfectly maintainable.


- Kevin