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.
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.
