Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It doesn't make it impossible, but it makes it a lot harder ($$$). Checking at least the root DNSSEC prevents them from setting up a simple proxy to their own DNS resolver. They instead have to inspect each UDP and TCP packets, determine which are DNS related, if they are for root, or any other server that has DNSSEC implemented, you pass them through.. you can proxy what's left. One of those smells a lot more expensive than the other.

Again. I'm not comparing this to DoH, but to only using your ISP's DNS resolvers. To me it still seems like an improvement.



You're not answering my question. I think maybe I didn't communicate this well enough: attackers already target the unsigned domain records; the ordinary M.O. of a DNS attacker isn't to intercept the root servers. How can you make it "a lot harder" for those attackers by layering more "security" on the root servers themselves?


> How does DNSSEC at the roots actually protect you from an attacker manipulating DNS?

Assuming that is the question you mean... it works by not allowing the attackers to take the easy course of hijacking all DNS queries and answering how they like. Instead they have to inspect each packet and only hijack those they can, which is a lot harder to do. So it is raising the bar in hope of raising it high enough that it isn't worth it ($$ wise) anymore to them. Part of this is that most people don't do this.. so the economics are not the cost of packet inspection for all their customers, but for a small fraction.


You're not following me. What you're saying is the "easy course" is neither easy nor the normal way DNS hijacking occurs. DNS hijacking typically starts with a target domain.


How do they pick out the target domain without packet inspecting all your DNS traffic?


If they were "packet inspecting all your DNS traffic", DNSSEC wouldn't matter to begin with, because it's a server-to-server protocol; your browser's resolver can't cryptographically verify anything. But that's not in fact what's happening.


But we are specifically talking a using a recursive resolver communicating with the root servers, server-to-server. The browser only comes into play here as a client to the local resolver. The original context was about a pi-hole running a recursive resolver directly against the root servers instead of the ISP's.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: