intelligent selection of forwarders?

James Ralston qralston+ml.bind-workers at
Wed Sep 4 03:44:54 UTC 2002

On Wed, 28 Aug 2002, Jim Reid wrote:

> James Ralston <qralston+ml.bind-workers at> writes:
> > 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.
> Indeed.  But as I said BIND9 has been out for two years now.  And
> folk have had to upgrade BIND8 fairly often in that time because of
> various security vulnerabilities.  So if they were going to upgrade
> a buggy server, they might as well have installed a decent version
> of BIND9.  Which probably has fewer security problems than BIND8
> anyway.

And as I said, BIND9 hasn't been production-quality for most of that

Upgrading the server is a step that some OS vendors (e.g., Red Hat)
have already taken.  But upgrading the resolver libraries is a more
complicated task.  (In fact, offhand, I don't know of *any* OS vendors
that are shipping resolver libraries based on BIND9.)

> > Using multiple forwarding servers can alleviate the single point
> > of failure.
> Not really.  The act of configuring a server to forward is the
> single point of failure, no matter how many servers it forwards to.

Could you please elaborate on your reasoning?

> > > 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.
> The bastion host can be compromised by cache poisoning, not by
> penetrating the host.

Penetrating the host will certainly compromised it.

> If an organisation is dependent on that cache, they lose.  And
> "important" caches like that present a juicy target.  If an
> organisation's name servers act autonomously, there's no juicy
> target and the impact of any cache poisoning attack is localised.
> ie The attacker breaks things for a department, not the whole
> campus.

I agree with you that a forwarding server (or a pool of forwarding
servers) can be a juicy target to a potential opponent.

But if an organization's name servers act autonomously, then *they*
simply become the juicy targets.  Even worse, these nameservers
probably aren't as hardened as dedicated forwarding nameservers, so
they're probably even easier (and thus juicier) targets.

I have no "religious opinion" on this issue; it's just that in my own
analysis, for many (most?) sites, the disadvantages of allowing all
nameservers and DNS resolver libraries to act autonomously outweigh
the disadvantages of using forwarding nameservers.

However, it's certainly possible that are potential disadvantages of
forwarding nameservers which haven't occurred to me.  If you can think
of any other potential disadvantages, I'd welcome counterarguments...

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

More information about the bind-workers mailing list