The author compares DNSSEC with other protocols like SSH and HTTPS. DNSSEC suffers from some of the same problems as SSL PKI, namely 1. it requires placing au

The author compares DNSSEC with other protocols like SSH and HTTPS. DNSSEC suffers from some of the same problems as SSL PKI, namely 1. it requires placing authority in people who you may not trust and 2. it's too easy to make configuration mistakes. But I suggest those alone are not the reasons DNSSEC has "failed". The reason it was a failure from the beginning (cf. the other protocols the author mentions) is in my opinion because it's aimed at authentication, and _only_ at authentication. And of course, like PKI, it tries to do this by delegating authority to some mysterious group of people. If it were aimed at _both_ encryption and authentication like SSH or SSL, then it could "fail" at authentication but still appear useful for encryption. In an ideal world, you could _authenticate_ with 100% certainty that you are connecting to a given remote computer and you could eliminate the MITM risk. We know that this is pure fantasy in today's world, though we try our best. Moreover, with respect to DNS, ICANN's and other third party DNS is usually anycasted, so what exactly are we authenticating with DNSSEC? Certainly not "the" remote computer with the zone file. Who is in charge of assigning a "root server" IP address to some interface on some computer in some datacenter sitting between you and the rest of the internet? Do you even know? Perhaps we are authenticating that the domainname is "legitimate"? According to who? Some third party? ICANN? It sounds a lot like PKI and SSL certificates. Personally, I would not rely on DNSSEC to confirm the existence/nonexistence of any domainname. If I can get a publicly available zone file from a trusted source, then I can serve that "root" and "TLD" information locally on the device. No need for the network. What I'm more interested in is confirming that the answer I receive from the authoritative nameserver (not the root or the TLD) contains the correct information, e.g., the correct IP address. Why shouldn't DNS traffic be encrypted, like, e.g., TCP/HTTP traffic? Going forward, I find dnscurve much more appealing than DNSSEC. It might not be a foolproof solution to authentication, but at least it offers encryption. The same can be said for SSH and SSL. To the author: Maybe that's why they have not been complete failures like DNSSEC.