DNSSEC and DNSCurve essentially do the same thing. They allow a client to verify that the records in a DNS response are identical to what the zone owner initially configured. They're not bulletproof; parent zones, registrars and registries can still do whatever they want with zones they are directly or indirectly authoritative for. But it's still better than nothing.
For this to work, zones obviously have to be signed.
Zones signed with DNSCurve are virtually nonexistent. The fact that it adds encryption is, in practice, completely useless; given the number of signed zones, the packet size is enough to guess what the query is.
DNSSEC is getting some traction, but its deployment remains pretty slow. Still, it remains far more deployed than DNSCurve, and popular tools such as openssh and mail servers can take advantage of it.
The most secure scenario is when the verification is done by the client itself. Or at least, if you trust your local network, on the router. Now that dnsmasq supports DNSSEC validation, router firmwares start to support it as well.
Now, by using a 3rd-party resolver and not doing any validation on your own network, you:
- blindly trust what the resolver sends to you.
- even if the resolver sends you a correct response, the network segment between the resolver and your client remains vulnerable to DNS spoofing.
If you are a Comcast customer, the DNS resolver is as close as possible from your router, and your connection completely depends on Comcast already.
If you are using another 3rd-party resolver, every hop between your router and that resolver can be used to potentially hijack the responses.
So, the best option remains using a local DNSSEC-validating resolver such as Unbound.
Malware doesn't care about DNSSEC or DNSCurve. Once your computer is infected, most malware can directly inject whatever they want into your browser, and change your DNS settings if required.
Privacy is a completely different topic, that just began being worked on (see the DNS privacy considerations RFC).