DNSSEC is Open for Beta

Yes, very sure. Because I actually had to sit down and read the relevant RFCs way back because it's part of my job as somebody who works for a domain registrar. Here's a quick overview for anybody who hasn't had the time to

You can't tamper with a record that's been signed. It won't validate against the matching RRSIG record, and the only way you can generate those is if you have the private key. And how do you validate those? Well, that's what the DNSKEY record is for: it contains the public key, and is used to validate the signatures in the RRSIG records.

Now, assuming you trust that modern crypto works, all that assures that records published in the zone cannot possibly be tampered with, but it doesn't prevent two things: the insertion of additional records and that the DNSKEY record is legit. For the former problem, NSEC/NSEC3 records exist.

[I'm not going to go into how NSEC/NSEC3 records work, because they're without a doubt the single most complicated part of DNSSEC. The rest of DNSSEC is trivial compared them, especially the mechanisms in NSEC3 records that mitigate against zone enumeration.]

So far so good, but while all that allows you to verify the integrity of the records you've queried, an intermediary could strip all those additional records that allow you to check their integrity or spoof them. You need to ask somebody, and given the inherently hierarchical nature of DNS, that somebody is the parent zone, which is where DS records come in: they prove that (a) the zone is meant to be signed and (b) that the DNSKEY record in the zone is legit. The same process is used right up to the root servers, whose contents is verified using the trust anchors supplied with your OS.

> If the plain text packet used in DNSSEC is tampered with then how does DNSSEC ensure I get an "accurate result"? Are you saying failure is an "accurate result"?

Failure tells you that the results you've got back have been tampered with. And that's a good thing. If somebody's feeding you poison, you need to know that.

I'll take a denial of service over somebody draining my bank account, and even then it needn't result in a DOS if you choose to ignore the fact that you've gotten bogus data.

> Where is control being placed? This smells much like SSL and the CA system.

Your problem isn't with DNSSEC, but with DNS.

> I obtain zone files from official zone file access programs and run them in my own authoritative nameservers, locally.

Which registries do you have agreements for zone file access with? And even if you have access to that information, you still have to get the zonefiles for the individual domains published in the registry's zone. How do you fetch those? I'm pretty sure that you don't have access to, say, the zones published on ns-22.awsdns-28.com, unless you happen to work for Amazon. So you're trusting somebody to fetch that likely incomplete that data for you from the real authoritative nameservers.

What you're running isn't an authoritative nameserver, not in the normal sense. You might be using it in authoritative mode to serve some scraped data locally, but effectively you have have is a little more than sophisticated /etc/hosts file and a bunch of blind faith that the sources you got the data from originally didn't tamper with it.

> I can also get zone information from the scans offered at scans.io

In other words, a third party who happens to have gathered the data, but who may just have tampered with it, and you have no way of knowing. All you have is blind trust that they're giving you good data. They could be feeding you complete junk for all you know. But DNSCurve makes sure that junk is transmitted super securely.

> After many years of workarounds, I can deal with that. It's the hierarchical nature of "trust" in DNSSEC (as in SSL) that is a problem.

It's DNS whose nature is hierarchical. The hierarchical nature of DNSSEC is a consequence of DNS being hierarchical.

> I guess we just differ in what we see as more important.

Yes, we do. I want to make sure the DNS records being served to me aren't junk. You want to fetch them using a gold-plated pipe, even if they happen to be total junk.

As I wrote before, DNSSEC and DNSCurve solve two totally different problems. In an ideal world, we'd be using both.

> I find it rather absurd that you are actually advising someone running their own cache to use DNSSEC.

When did I write that? The only thing I've talked about is the importance of being able to verify the integrity of the data you've fetched.

> There are commercial interests pushing DNSSEC. Its advocates will make any argument necessary to try to justify adoption.

For what benefit? What do they get out of it?

DNS hosting providers don't get much out of it except having to serve more data. Registrar's don't get much out of it except of yet another EPP extension to implement that no registry implements the same way and yet another obligation if they're on the 2013 RAA. Registries don't get anything out of it except having to serve more data. Registries don't charge for DNSSEC, and it's no more in a registrar's interest to charge to send DNSSEC requests up to the registry than it is to charge for nameserver or contact updates. DNS hosting providers could charge, and some do, but given the choice between using using the likes of OpenDNSSEC and stabbing yourself in the eye with a pencil, the latter will typically win out. And if you're a masochist like me, you can use a hidden primary and treat all the visible authoritative nameservers as secondary nameservers, so if your DNS hosting provider allows zone transfers, you don't have to pay anything extra because the DNS hosting provider doesn't have deal with securing the private key and all the implied expense of doing so.

So, who is actually benefiting here? The manufacturers of hardware security modules? As far as I can see, they're the only ones who potentially win big from a financial point of view from DNSSEC.