Dangers of DNS
This article is just not helping my brains at all. How did the user get the malware in the first place such that their resolvers were subverted? Certainly, not through a nameserver - it would have to be some other way that the user was sent to get it first, from an "Address" running - what, a web server that is being referenced by other rogue DNS servers? Why on earth are bad DNS sites in any way needing to be recursive? And how many open hosts were real bad, and how many just weak and cache-corrupted for evil? And last of all, where did they get these impressive figures - scan of the entire net's nameservers for answers to the address lookups of the vast majority of known-scammed sites? Nope, I need the paper.
@Gordon Fecyk, re recursion: there's nothing wrong with recursion as such (some servers are deliberately configured to be open in spite of potential cache poisoning); like you say, you kinda need it. The rest of the world doesn't, though, so you'll have to somehow get your nameserver only to answer recursive queries from given netranges - those owned/operated by your clients. Running your own caches really is a very sensible thing to do, and is good to the net.
The reason recursion is a "Risk" has more to do with the fact that DNS is a stateless protocol running on UDP. It usually takes just one UDP packet in both directions from query source to nameserver and back to get a recursive DNS query answered (and that's in total if the server need not chase up). Apart from the obvious fact that you don't want anyone that doesn't need your resources to get the benefits of your caches' RAM/CPU when you're following the recursion every time you get asked about places you've never heard about, opening recursion to everyone means giving a potential bad person the ability to cause your nameserver to make outbound queries whose results will be cached on the attacker's demand. (He may, in fact, be able to do this already, for instance by connecting to a service that does RDNS checks or sending mail so that an MX lookup is performed as part of the antispam check, but at least he usually can't make too much out of that when his goal is taking over your web browser.) Obviously, his idea is that you take the word of authority from the attacker as response to your nameserver's question, not data from the legitimately authoritative host, and then cache it for a suitably lengthy time (the time to cache the record is in the TTL field of the record the attacker forged, rather helpfully). If your attacker is on the same physical network as your nameserver, he can simply race a response to its queries before the genuine response gets in. And he can answer on behalf of your nameserver when it is queried from outside - so he can replace your web pages and take your incoming mail. If the attacker is not on your network, weaknesses in the randomness of certain aspects of generated packets (IP source port and query ID) can be learned by experimentation of an attacker - perhaps by making your nameserver query one under his control - and the suitable response to a malicious query (one for which the attacker actually wants you to cache bad data) anticipated and forged in the genuine server's address (this is much, much harder though; the patches for BIND were fixing exactly this kind of weakness - namely, by copying better code from BIND 8 into BIND 9).
In summary: best not allow recursion when not necessary. It really makes sense. For local attackers, it's just asking for trouble - not that they haven't got other, much more result-giving alternatives to try (ARP spoof ...) in case that doesn't work. But if your nameserver is isolated somewhere near a border, attackers are still possibly able to do bad things - fill up your RAM and maybe poison you.
I know it was barely English, but I hope that helped!