This happened to me in September 2005. It's presented as a tale of caution.
NOTE: Names have been changed to protect the guilty. Available on request, if someone wants to verify.
I was visiting family, and as is my habit, I went to their computer to check on the status of the Linux Counter Project - http://counter.li.org.
Much to my surprise, what popped up on the screen looked suspiciously like a generic no-brand search engine, and nothing like my friendly project page at all - in fact, despite a few occurences of "li.org" on the page, it had absolutely no sign of a contact address at all.
A few days of intensive investigation followed, uncovering a tale of woe, detailed below.
It seems that the domain in question was served by a few secondary nameservers at [dupe].com. The domain [dupe] had at some point, probably in the last few months, been taken over by [evil guy]. And this guy, rather than just taking down the nameservers in question, had instead pointed the name servers for [dupe].com to a set of name servers with some special properties:
As a shorthand, let's call the NS server ns1.[evil].com. There's an ns2 here too, but it does the same thing.
The result:
In the normal process of resolving a name, say [victim].org, a resolver asks the TLD servers for the nameservers for the domain. Some of these are the normal servers; some are of the form nameserver.[dupe].com. (Remember - [dupe].com has been taken over by [evil guy]).
It then turns to the [dupe].com domain and asks for the A record of one of those nameservers - and the listed nameservers for [dupe].com are ns1.[evil].com and ns2.[evil].com.
ns1.[evil].com will then tell the client that the nameserver for [dupe].com is at the address of ns1.[evil].com. Unless you have reason to suspect that it's elsewhere, you will notice no change - the name is still ns1.[dupe].com.
The client then requests an A record for [victim].org, thinking it's sending it to ns1.[dupe].com - but the request goes to ns1.[evil].com, which cheerfully points the requester to [evil guy]'s Web page. Capture complete.
Of course, if the requester in step 2 above happened to pick a nameserver that was not in the [dupe.com] domain, it would get a perfectly normal resolution, and the page that was wanted. So when a service technician goes looking for the problem, he's quite likely to conclude that "all is well", and write it off as a "glitch".
But it isn't.
I believe the behaviour of [evil guy] in the scenario above is deeply unethical. It may also be illegal under some jurisdiction; I don't know.
What's for sure is that this behaviour is not innocent.
For the potential victim, the moral is probably "know your secondaries" - have a continuing relationship with them, and know what's happening to them. And CHECK.
Deployment of DNSSEC would have prevented this. Not because it would keep the NS resolution capture from happening (after all, [evil guy] is perfectly entitled to run [dupe].com, with or without DNSSEC, once he's captured it), but because if [victim].org is a signed zone, the requester will know that in step 1 (DS record), and the A record purporting to be for [victim].org in the last step of the attack won't have a valid signature. Sound the alarm, disable the evil nameserver, ask another nameserver and congratulate yourself on a foiled attack.
The general threat is described in painful detail in section 2.4 of RFC 3833. This is just one special instance of it.
Be careful.