Why forwarding is a Bad Thing

[Simon Waters]

Jim Reid wrote:
> 
> 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. :-)

That would require me to have been SANE. *8-) Besides it's better than
another 'why dosn't my BIND server work?' when the answer is in the
documentation.
 
> 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.

Clueless admins don't have a chance - you have to train them - why would
you have a clueless admin run anything this important? Duh... Okay I'm
convinced.

> [2] Forwarding set ups are usually not documented at all.

This doesn't seen a problem to do with forwarding.
 
> [3] The addresses of the forwarding targets get hard-wired into config
> files.

And what about ns_root.c in BIND 9 - hard wiring in some nominum
preferred root servers tsck.

..SNIP... More documentation complaints.

> If all the forwarding name servers are
> not under one single control, it can be almost impossible to do
> anything to the target servers.

Similar arguments apply to routers - at the end of the day you have to
document your network or suffer the consequences.

> [4] Forwarding is just dumb. 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.

Computers excel at doing simple dumb things repeatedly.

Is that RRT stuff in the documentation? As I didn't see it under
forwarders.

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

That is why you have more than one, I agree that they are potentially
less robust than the Internet root servers. Although come to think of it
at least one pair I use appear to be more reliable than the Internet
root servers.

So forwarders add resilience through additional caching when the
Internet root DNS goes down <tongue in cheek>. Lets hope are PTR's live
longer than their A's *8-)
 
> [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

Only one machine this end of a 64Kbps line but I get a substantial
benefit in using forwarding to my ISP's DNS when surfing the web over a
local DNS resolving off the root name sevrers. Which I have documented!
Possibly my ISP's DNS being primed by nearly quarter of a million other
users helps.

Of course I don't have to forward-only.

> [7] Forwarding name server architectures tend to become baroque.

Hmm - more clueless admins?
 
> [8] A name server will usually be quicker resolving things for itself
> than forwarding the queries elsewhere for resolving.

You got figures for that - I've got the opposite - to as much as 1/3rd
second per lookup. Your ignoring caching - that is the whole point of
using forwarders.
 
> [9] Forwarding can create extra and unnecessary traffic on the
> internal net.

My experience is that the Internet connection is the bottleneck. Maybe
I'm too european.
 
> [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....

Your losing me here. As opposed to what? Configuring every zone to be
zone transfered?
 
> Now sometimes forwarding is the only option: say because of firewall
> access policies....

Ah - so forwarders mean you can apply a tighter security policy -
perhaps I'm showing my roots as a firewall installer.

I agree forwarders confuse mortals, and can reduce redundancy, but they
can increase security and performance. 

I'm tending to prefer just not allowing DNS through to the inside where
I might have been tempted to use forwarders before. Rather than forward
the DNS, just forward the web requests or the e-mail. Thus Trojans would
have to shout a little louder to talk to the outside world (https
anyone).

-- 
Want to learn about Linux? Get it installed?
Devon and Cornwall LUG Event for UK Linux Day 
Exeter University - Sunday April 29th 2001 10:00 to 17:00
www.linuxday.org.uk or join D&C LUG www.lug.termisoc.org