Re:The DNSSEC master key securing DNS is about to change
by tptacek on Monday August 29, 2016 @05:07PM
(#12385330)
If we're going to accept that shit is broken and we should go ahead and fix it, why can't we fix DNSSEC itself? It's a terrible, broken, already-obselete protocol that sees virtually no meaningful real-world deployment. Why would we spend tens of millions of dollars to deploy something we already know is broken.
Re:The DNSSEC master key securing DNS is about to change
by bluejekyll on Tuesday August 30, 2016 @01:38PM
(#12392136)
see my comment in a sibling thread: https://news.ycombinator.com/item?id=12392121
Is your point that we trust Google's DNS too much?
> most batshit aspect of DNSSEC: validation is done on the servers and not on the endpoints (you "can" do endpoint validation, in the same sense as you "can" run your own recursive caching server locally).
You "can" and we "should" be validating this at the client. So why don't we start doing this? We should be beating on the security layer in DNS as heavily as we do with HTTPS and other TLS implementations.
> This is a relic of the early-mid 1990s, when the core DNSSEC design was finalized and any kind of encryption was thought to be too expensive to deploy to end-systems. It's also the reason DNSSEC is signing-only, with no privacy protections.
There are several proposals at this point that resolve the privacy issue, DNSCrypt, DNSCurve, and DNS over TLS.
> But we're still forced to live with that bad decision, because nobody in the IETF wants to admit they were wrong
Given the number of revisions to the DNS RFCs, specifically around DNSSec, I don't think it would be accurate that they didn't admit being wrong, people are constantly working to resolve issues with the system.