intelligent selection of forwarders?

Jim Reid jim at
Tue Aug 20 07:26:14 UTC 2002

>>>>> "James" == James Ralston <qralston+ml.bind-workers at> writes:

    James> I want to be able to conduct periodic maintenance (e.g.,
    James> rebooting one of the forwarders) with minimal disruption
    James> (e.g., without having our internal nameservers blindly
    James> querying the forwarder while it's rebooting).

Don't you have maintenance windows? Not that this matters: DNS setups
that involve forwarding are pretty much broken.

    James> Also, if a site's name servers aren't all running BIND9,
    James> then using BIND9 forwarding servers can help mitigate
    James> attacks against buffer overflows in DNS resolver libraries:

That seems to be an argument for upgrading to BIND9 -- it's been out
for 2 years now -- rather than use an undesirable and suboptimal name
server configuration that depends on forwarding.

    James> (Generically and generally speaking, forcing one's DNS
    James> traffic to all flow through bastion forwarding hosts is a
    James> good security practice.)

In your opinion. It may be marginally useful for security -- don't see
that myself -- but it introduces a glaring single point of failure. 
And it's bad a security perspective too. As well as being bad for the
availabilty of resolution service. Compromise a bastion host, say by
poisoning its cache, and a bad guy can inject bogus data all over your
organisation. The rewards can make that attack worthwhile because the
impact is so great. If the bad guy can just compromise a local name
server, the damage is not as bad: some department has a problem, not
the whole campus.

Forwarding is rarely if ever a good idea. To give an analogy, there
are several ways of getting from Pittsburg to New York. Do you always
go by car? With the same car? Would you take a different route if a
road was congested? Or take a train if the airlines were not flying?
I presume you'd allow yourself some flexibility. So why not let your
name servers have the same thing instead of blindly (and stupidly)
forwarding queries to the same place? To continue the analogy, this is
like always taking the same road even when you know in advance there's
a bridge ahead and it's out.

More information about the bind-workers mailing list