Bind Software diversity

[Ladislav Vobr]

Jonathan,

    thanks for your detailed reply. I am already aware about the points 
you listed, and their implementation is not the short one in our case, I 
was just trying to get some opinion from people running different 
multi-vendor or multi-version dns solutions, their experience, and 
problems, since my goal is (after fixing these very basic things, and I 
agree with you ) to have maybe the multicultural dns.

Ladislav

Jonathan de Boyne Pollard wrote:

>LV> what is the opinion of the bind community ?
>
>The opinion of "the BIND community" when asked, in essence, "Rather than run
>the very latest version of BIND throughout, should I run different, non-BIND,
>DNS server softwares?" is, I suspect, going to be the obvious one.
>
>However, I think (as Simon also alluded) that you are addressing the wrong
>thing.  Rather than attempting to reduce the impact of any attacks from the
>malicious by avoiding monoculture, you should be concentrating on restricting
>who can actually make such attacks in the first place.  You should be
>concentrating upon restricting who is actually _able_ to abuse your services,
>to your paying customers, before concentrating upon dealing with the
>_consequences_ of such abuse.
>
>For example:  
>
>If your organisation is indeed the one named in your mailbox, and if your
>organisation's web page is to be believed, your
>
>	LV> three public recursive servers serving large 
>	LV> number of customers
>
>are in fact 194.170.1.6 and 194.170.1.7.  These are also (two of) the content
>DNS servers for "emirates.net.ae.".  (And thus, presumably, 194.170.1.99 is
>the third "public recursive server" that is not listed on your organisation's
>web page.)  Because these are publically reachable IP addresses, you are
>providing resolving proxy DNS service to the world.  You thus haven't followed
>the advice on page 321 of _DNS & BIND 4_.
>
>One consequence of this is that anyone on the whole of Internet can trigger
>any attack that requires a certain pattern of queries to be sent to your
>servers.  Another consequence of this is that anyone on the whole of Internet
>can cause your proxy DNS servers to do work, for which you pay the network,
>storage, and processing costs.  (Remember: Even checking an access-control
>list and dropping a query is work.)  A third is that any compromise of your
>proxy DNS service also compromises your content DNS service, and vice versa.
>
>Rather than concentrating upon software diversity, you should be concentrating
>instead on the fundamentals of your service exposure.  Only your paying
>customers should be able to even reach the IP address on which you provide
>proxy DNS service to them.  The rest of Internet, against whom you do not have
>the contractual remedy available in the event of mis-use that you have with
>your paying customers, should not be able to do so.  For best results, your
>proxy DNS servers should be listening on IP addresses in one of the non-public
>network ranges; so that traffic from a potential attacker doesn't even leave
>his/her organisation and cross Internet, let alone reach yours.  Your proxy
>DNS servers _certainly_ should not be the same as the "emirates.net.ae." - or
>indeed any other - content DNS servers.
>
>You've made your proxy HTTP service inaccessible to the rest of Internet and
>disjoint from your content HTTP service, because of similar, parallel,
>considerations in the world of HTTP.  You should perform this basic measure on
>your proxy DNS service also; before worrying about other things.
>
>  
>