Arguments for/against use of forwarders{}?

Jim Reid jim at rfc1035.com
Sun May 20 15:03:57 UTC 2001


>>>>> "Len" == Len Conrad <LConrad at Go2France.com> writes:

    >> If you forward, you depend on whatever you forward to be always
    >> available to answer queries. If the target(s) of those
    >> forwarded queries die or misbehave or get renumbered or have
    >> their configuration changed, you lose.

    Len> ok, that assumes the forwarder is not chez vous.

It holds for any forwarding setup. The same Bad Things will happen if
you forward queries to an internal server that's no longer there or not
running a recursive name server any more, etc, etc. The only
difference is that there might be a better chance of fixing a broken
local server than a remote one managed by somebody else.

    Len> So let´s assume the forwarder IS local in our local DMZ as a
    Len> bastion DNS, taking queries from one or more DNS´s inside the
    Len> inner firewall, keeping DNS queries through the inner
    Len> firewall to recursive only.

    Len> Single point of failure, sure, but it´s local.

    Len> What´s the argument against that config? 

It introduces an unnecessary single point of failure. Why take that
risk? The internal name servers could just as easily make their own
queries through the firewall(s) directly to the internet. IMO the
"benefits" of forwarding are insignificant -- who *really* cares about
slightly fewer lookups? [There's probably not that many fewer queries
if the server looked things up for itself instead of forwarding.] They
are not justified by the added complexity in administration, not to
mention the introduction of a SPoF that doesn't need to be there.


More information about the bind-users mailing list