intelligent selection of forwarders?

[James Ralston]

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

Using multiple forwarding servers can alleviate the 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.

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

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

    You perform a security analysis of your company's business
    practices, and realize that there are multiple security
    weaknesses.

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

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

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

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA