[jingo]

"... armour the requests themselves to make sure that they don't become the new vector, they don't become manipulated."

I interpreted this to mean encrypting each DNS packet.

Maybe I misread the statement?

DNSSEC of course does not protect the contents of the packet.

Instead, DNSSEC more or less is just another CA system (or an adjunct to the existing one), running over UDP.

[nly]

You're confusing vanilla DNSSEC with its proposed uses/abuses. DNSSEC just enforces the trust model that was already in place (the hierarchical nature of DNS) to ensure the authority and integrity of DNS responses. It doesn't provide confidentiality because that simply doesn't work in the shared DNS forwarder+cache model we all currently depend upon, much like HTTPS renders shared HTTP caches useless (which has implications for CDNs for example).

Proposals like DANE, using TLSA records, or deploying SSHFP records on DNSSEC enabled domains, are a different kettle of fish.

Whether or not you believe in DANE really depends on whether you're willing to accept that the DNS infrastructure is already security critical. Truth be told, if I can hijack your DNS, I can get a certificate for your domain using simple domain validation... but that's true of your web server as well. There's no easy answer here.

[mnot]

That would be DPRIVE, which he mentioned as well -- http://datatracker.ietf.org/wg/dprive/charter/

[jingo]

Well, at least they are acknowledging the need.

I use my own cache, not shared with anyone. Do I really need to worry about snooping?

I also use CurveDNS with the authoritative server that serves my version of the root.zone.

Practicing my CurveDNS skills for that day when more authoritative servers are using curvedns. Not sure that day will ever come.