Thankfully, the article you linked links to its sources... which don't back up the claims it makes. From the link it uses to say that DNSSEC doesn't help end users against spoofing:
"Although DNSSEC solves many of the security problems with DNS, it is not widely used because of the large cost of transitioning from DNS. However, where available, DNSSEC protects against the DNS attacks in Cafe Crack and should be used by Internet users."
Almost the exact OPPOSITE of the claim.
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
DNSSEC client support is much more widely deployed and activated on servers, but implementations exist for end-user OSes, and that hop of security is clearly the goal here. It's just that no consumer OS turns on support by default, because server-side deployment numbers are so low. And the packages that do exist are a royal PITA to install (in the OSX case) or configure (in the desktop Linux case). (Side note - still no DNSSEC for desktop Windows, according to my latest Google search.)
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
There is a difference between the way TCP/IP works when sites like HowStuffWorks describe it, and the way it works in the real world.
In the real world, when you type a site name into your browser bar, your browser invokes a stub resolver to send a DNS query to a DNS recursive cache server, which is virtually never running on your local machine.
So, however it's supposed to work in theory, in practice there is DNS traffic running between your machine and some server somewhere on the Internet (perhaps very far away on the Internet if you use OpenDNS or Google DNS), and DNSSEC does not protect those queries. They're flying around the network in plaintext protected only by a 16 bit plaintext query ID and somewhat less than 16 bits of entropy in source ports, if you're lucky.
I'm pretty sure I can speak reliably for what that article I linked to claims.
On most desktop Linuces I've dealt with, the "stub resolver" is dnsmasq, which is quite full-featured and DNSSEC-capable... except that distributions don't enable the feature or distribute a trust anchor. But there aren't any deep structural problems preventing them from flipping the switch [1] - not like, say, the deep coupling between layer 3 and layer 4 that killed SCTP and other TCP/UDP alternatives in practice.
[1] For example, this configuration change is all that's required to enable DNSSEC on Gentoo, and would probably also work on Ubuntu and Fedora: https://wiki.gentoo.org/wiki/Dnsmasq#DNSSEC
Linux is a test case. If you can get Linux to use DNSSEC without cooperation from intermediate routers and caches, then it's just single-organization engineering work - Apple and Microsoft would need to write DNSSEC-capable client implementations (which Microsoft already has for Windows Server) and deploy them. This is an OS feature like any other OS feature.
The obstacles to changing to IPv6, or to making any changes whatsoever to TCP, just aren't there.
Because it takes non-zero work, and doesn't add much value on top of SSL/TLS, which got wide deployment first.
As far as I understand, IPSec + DNSSEC gets similar security guarantees to SSL/TLS without identity certification, so once you have one there isn't any real economic incentive to put massive effort into developing the other.
"Although DNSSEC solves many of the security problems with DNS, it is not widely used because of the large cost of transitioning from DNS. However, where available, DNSSEC protects against the DNS attacks in Cafe Crack and should be used by Internet users."
Almost the exact OPPOSITE of the claim.
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
DNSSEC client support is much more widely deployed and activated on servers, but implementations exist for end-user OSes, and that hop of security is clearly the goal here. It's just that no consumer OS turns on support by default, because server-side deployment numbers are so low. And the packages that do exist are a royal PITA to install (in the OSX case) or configure (in the desktop Linux case). (Side note - still no DNSSEC for desktop Windows, according to my latest Google search.)