intelligent selection of forwarders?
jim at rfc1035.com
Wed Aug 28 15:52:59 UTC 2002
>>>>> "James" == James Ralston <qralston+ml.bind-workers at andrew.cmu.edu> writes:
>> 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
James> This is an overly simplistic argument.
James> Being able to upgrade the nameserver and resolver libraries
James> on every single operating system in one's organization to
James> BIND9 instantaneously and effortlessly is sheer fantasy.
James> 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.
James> Using multiple forwarding servers can alleviate the single
James> 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.
>> 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.
James> Irrelevant; if the bastion host can be compromised, then in
James> all probability, any DNS server in the organization can be
Read what I said. The bastion host can be compromised by cache
poisoning, not by penetrating the host. 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.
More information about the bind-workers