Why forwarding is a Bad Thing

[Jim Reid]

>>>>> "Brad" == Brad Knowles <brad.knowles at skynet.be> writes:

    Brad> 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.

    Brad> 	Really?  I wasn't aware that you felt this way.

Well I've made my views about forwarding known many times here. And I
suppose you must have been asleep when the topic briefly came up in my
tutorial at SANE last year. :-)

    Brad> 	If you don't mind, I'd be extremely interested to
    Brad> learn as much as I could from you as to why you feel that
    Brad> this strategy is a bad idea.

OK. Here goes:

[1] Clueless admins don't understand the concept. They mistakenly
believe that if the first forwarded target doesn't give the desired
answer, the name server will try the second. And so on.

[2] Forwarding set ups are usually not documented at all. This gives
rise to all sorts of nasty operational problems. Server A forwards to
B which forwards ... to A. Debugging those subtle SERVFAIL errors can
be entertaining. Or if some server's cache has bad data, finding out
how it got there and tracing it back to the source of the problem can
be troublesome.

[3] The addresses of the forwarding targets get hard-wired into config
files. [Why not let your server find the addresses of other name
servers for itself by following the NS records?] They also end up in
folklore: the details are passed by word of mouth between system
admins without knowing if the info is correct or even
appropriate. Having the addresses bolted into config files makes it
very difficult to renumber or relocate the target(s) of forwarded
queries. Suppose that everything forwards to the firewall and a new
firewall has to be deployed... If all the forwarding name servers are
not under one single control, it can be almost impossible to do
anything to the target servers.

[4] Forwarding is just dumb. A name server has the intelligence to
navigate the name space, locate other name servers, work around
dead/lame ones, measure round trip times and pick the closest servers
and generally look after itself. Instead of letting the server use
those capabilities, forwarding constrains it to blindly throw queries
at a small number of servers. This is a bit like buying a Ferrari and
then chaining it to a lamp-post so it can only go round in circles at
5-10kph. At least with 8.2.3 and BIND9, the forwarding server can at
least exploit the RTT to the targets to pick the fastest one.

[5] The target(s) of forwarding become single points of failure. If
they stop, DNS stops and the sky falls in.

[6] The benefits of having a single central cache for all to share are
over-hyped IMHO. They may have been valid in the days when a
campus-sized net had one 56/64k line and every off-site packet was
expensive, but not today. Is there *really* a lot of synergy from
having all the organisation's web servers and mail servers (say)
resolve on one name server cache? And what about having all the eggs
in one basket?

[7] Forwarding name server architectures tend to become baroque. As a
result they are prone to be vulnerable to subtle N-th order
problems. Suppose server A forwards to B which forwards to C and B
fails. Or gets switched off. Or renumbered. What breaks? How does the
problem manifest itself? How is it debugged? Remember too that the
administrator of A probably doesn't know their name server forwards,
let alone where it forwards to. And the administrator of B doesn't
realise that A forwards to it. See [2]. For added amusement, now add
per-zone forwarding to the mix. Or wildcarding.

[8] A name server will usually be quicker resolving things for itself
than forwarding the queries elsewhere for resolving. The work to
resolve the name will be the same whether the forwarding or target
server does the job. So why introduce another (unnecessary) link --
in reality a single point of failure -- in the chain?

[9] Forwarding can create extra and unnecessary traffic on the
internal net. The numbers of queries and answers are usually doubled.
This can sometimes be amazingly stupid. Suppose a forwarding server in
London can only forward to a server running on a firewall in New
York. The London server has to resolve a name that lives on name
servers elsewhere in London. So instead of a hopefully quick local
lookup the query goes from London to New York to London and back
again. Ho hum.

[10] When using forwarding with split DNS, every forwarding target
server has to be configured with the details of every apex zone in the
internal name space. This can be very messy to set up and
maintain. And it probably won't be documented....


Now sometimes forwarding is the only option: say because of firewall
access policies or dial-up internet connectivity or (shudder!) NAT. In
these cases, I would grudgingly use forwarding if someone put a gun to
my head. Other than that, I'd avoid using or setting up forwarding
name servers if at all possible.

I realise your experiences at AOL have given you a warm feeling about
forwarding. I wasn't in that environment, so I can't say for sure if
this was the right way of solving the problem you described. It
doesn't seem to me that forwarding was needed or that your
"consistency" rationale justified it. [Maybe I don't understand the
problem or haven't thought hard enough about it.] There's always a
window when name servers are inconsistent: when the master has loaded
new data for a zone but the slaves haven't. I don't see how your
forwarding setup solves or mitigates that problem.