Why forwarding is a Bad Thing

[Jim Reid]

>>>>> "Simon" == Simon Waters <Simon at wretched.demon.co.uk> writes:

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

    Simon> This doesn't seen a problem to do with forwarding.

True. But there's a very strong correlation between the absence of
documentation and the use of forwarding name servers. I wonder why?

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

They are not "Nominum preferred", they *are* the root servers. I
suppose Nominum prefers them, just like everyone else does. Well apart
from the crazies who set up their own rival Internet roots.

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

    Simon> Similar arguments apply to routers

Not really. Routing protocols automatically reconverge after a router
is switched off. If a name server only forwards to another server, and
that server disappears, it can't recover from that.

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

    Simon> Hmm - more clueless admins?

No. Misguided ones. Or those who stumble on a configuration that "works"
by a process of trial and error.

    >> [8] A name server will usually be quicker resolving things for
    >> itself than forwarding the queries elsewhere for resolving.

    Simon> You got figures for that - I've got the opposite - to as
    Simon> much as 1/3rd second per lookup. Your ignoring caching -
    Simon> that is the whole point of using forwarders.

True, I did ignore caching. The benefits are dubious: your claimed
third of a second speed up is unlikely to matter. Try running a
forwarding and non-forwarding name server. Can you really tell the
difference in lookup times unless you measure them with a stop watch?
And anyway I'd rather have *my* servers find things for themselves
than run the risk of getting crap from forwarding to a server run by
somebody else. BTW caching isn't "the whole point" of forwarding. The
main reason for forwarding is because many sites have policies or
network architectures which restrict which servers are allowed to
query the big bad outside world. In these environments, forwarding is
the only means of resolving external names.

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

    Simon> Your losing me here. As opposed to what? Configuring every
    Simon> zone to be zone transfered?

No, letting the name servers find out things for themselves.
 
    >> Now sometimes forwarding is the only option: say because of
    >> firewall access policies....

    Simon> Ah - so forwarders mean you can apply a tighter security policy

No. You can apply a security policy. Whether it's tighter or not than
a different security policy or network architecture is debatable. 

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

I disagree on security: what difference does it make which servers can
send and receive queries through the firewall? Really. The larger
cache of the forwarded server can sometimes make lookups faster, but
not enough to make a significant difference. [Suppose you have an
application that looks up foo.example.com 1000 times. Apart from the
first lookup, they all get answered from the local servers's
cache. Does it really matter in the overall scheme of things if that
first lookup took say 2 seconds (doing the lookup itself) or 200ms
(forwarding)?] BTW that remote cache makes things *far* less secure. You
have no idea what's in it or where those RRs came from. If that cache
gets poisoned, your forwarding server does too. Charming.