Starting at the client level, whether it is a browser, mail server or mail client. At the moment very few clients have native support, and most seem to need to be patched which is not something the vast majority of end users would be comfortable doing. Microsoft only seem to be supporting DNSSEC in Windows 7 and Windows 2008, although I could be wrong on this. Then there's the variety of browsers on the variety of mobile devices. In all cases it's more likely that you'll have IPv6 support!
The next step would be the dns resolver that the client talks to. This could be your ISP's resolver, your local router, a third party such as OpenDNS and Google or possibly a dedicated local server. At the moment then chances of them being DNSSEC enabled is minuscule.
In the case of local routers (CPE), Nominet tested a cross section of CPE devices in 2008. The result?
As a consequence, we conclude that just 6 units (25%) operateOf course even if the router supports DNSSEC, you then have to make sure that the upstream DNS servers support it, which is by no means a given. Comcast are still only testing it which probably puts them well ahead of their competition.
with full DNSSEC compatibility "out of the box." 9 units (37%)
can be reconfigured to bypass DNS proxy incompatibilities.
Unfortunately, the rest (38%) lack reconfigurable DHCP DNS
parameters, making it harder for LAN clients to bypass their
interference with DNSSEC use.
Then you have to make sure that any firewalls between you and the upstream DNS server are correctly setup. It's not unknown for Network Admins to only allow UDP packets over port 53. This will break horribly with DNSSEC as the response to a query will be a lot bigger so it's very likely that the server will have to fall back on TCP. Even if the the Network Admin has opened TCP port 53, it's possibly that the firewall "knows" that a DNS packet can ever be larger than X bytes, and will indiscriminately drop any packets larger than it's set limit.
Then there's the root servers and the various TLD servers. The earliest that we'll see a signed root zone is July 2010, and that's presuming that their testing goes well. PIR have implemented it on .org already, and various other cctlds have either implemented or have testbeds. Verisign have said that Q1 2011 is when they expect to have it rolled out for .net and .com.
Presuming that all the above has been fully implemented, it's possible that DNSSEC would have stopped what happened on Mar 24th. However, then there's the leaking of more specific routes such as what happened Youtube in 2008, but that's a different problem with different fixes.
The above is only a very quick and nasty overview of the issues with DNSSEC at the moment as far as a client is concerned. There's plenty of other issues to be sorted out such as transferring domains and key rollover among others.
Then there's the human element. Phishing won't be cured by DNSSEC, most phishing attacks use absolutely random urls, such as http://this.is.a.fake.url.com/path/to/bankhomepage.com/login.html. The deployment of DNSSEC also won't force people to upgrade their browsers, IE 5 and IE 6 still make a good percentage of the the browsers out there!
Unfortunately, DNSSEC is going to remain very much pie in the sky for the time being.