intelligent selection of forwarders?
qralston+ml.bind-workers at andrew.cmu.edu
Wed Aug 28 04:56:49 UTC 2002
On Tue, 20 Aug 2002, Jim Reid wrote:
> >>>>> "James" == James Ralston
> >>>>> <qralston+ml.bind-workers at andrew.cmu.edu> 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?
It's not always feasible and/or convenient to wait until the next
maintenance window. In such cases, being able to minimize the
disruption that performing maintenance causes is a desirable thing.
> 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
> James> 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.
This is an overly simplistic argument.
1. It took quite a while (and no doubt a lot of work on the part
of ISC) for BIND9 to become stable enough to run in a
production environment. (And although I mean no offense to
the BIND9 developers, I know people who insist that BIND9
still isn't stable enough to run in a production environment.)
2. Most operating system vendors are still shipping BIND8 (or
BIND8-based) nameservers and resolving libraries in their
operating systems. (For example, Solaris 8 ships with a
patched version of BIND 8.2.2.)
Being able to upgrade the nameserver and resolver libraries on every
single operating system in one's organization to BIND9 instantaneously
and effortlessly is sheer fantasy. Migrations take time.
> 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
Using multiple forwarding servers can alleviate the single point of
> 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.
Irrelevant; if the bastion host can be compromised, then in all
probability, any DNS server in the organization can be compromised.
> Forwarding is rarely if ever a good idea. To give an analogy, there
> are several ways of getting from Pittsburg to New York.
It's "Pittsburgh", not "Pittsburg". ;)
> 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
I don't see the relevance of your analogy.
This is the metaphor I like to use for forwarding servers:
You own a company based in a city. Your company is highly
dependent on gathering documents from people and businesses
located throughout the city. Thus, your employees spend hours
each day traveling over the city, gathering these documents, and
bringing them back to your company. (Yours is a 24x7 business;
your employees travel all over the city, at every hour of day and
You perform a security analysis of your company's business
practices, and realize that there are multiple security
First, many of your employees aren't smart enough to realize a
setup, and could be tricked into carrying bogus documents back to
your company. Even worse, some of the documents could be
contaminated with chemical or biological agents; the vast majority
of your employees wouldn't have the skills or the training to
Second, although some of your employees are physically fit and
have self-defense training, many are not, and are ripe targets for
muggers, thieves, and kidnappers. A determined opponent could
kidnap one of your employees, brainwash him, and then allow him to
return to your company in order to act an agent of the opponent.
Your analysis determines that these security threats are
significant. Therefore, you decide to change your business
Instead of having all of your employees traversing the city, you
decide to hire several individuals to act as dedicated couriers.
These couriers are all ex-Marines with full combat training, who
keep themselves in meticulous physical shape. You buy armored
vehicles for the couriers, and make sure to keep them supplied
with the latest self-defense weapons and technology. You train
them how to spot forged documents, or documents containing
chemical or biological agents. Finally, in order to mitigate
against the scenario in which the couriers are somehow captured
and brainwashed, the couriers are confined to a "jail" area of
your company's facility, and have no access to (or privileges in)
any other area; employees issue document requests to (and receive
documents from) the couriers via a bulletproof double-partitioned
window, which makes it impossible for the couriers to physically
contain any other employee.
Now, the courier solution isn't perfect, as it's still possible
that your couriers could unwittingly deliver forged documents back
to your employees. And now that your regular employees aren't
traveling the city themselves, if something happens to the
couriers, your business will grind to a halt until the couriers
are running again. But the latter risk is mitigating by your
having multiple couriers, and the former risk can never be
completely eliminated. Overall, you have reduced the security
risks to your business.
I can see your points about a single point of failure and
vulnerability, but I find it difficult to envision a situation in
which the alternative (every machine being a point of attack) is
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
More information about the bind-workers