I don't get why you'd think direct to the root DNS servers would be worse than using your ISPs servers. Using the root servers means you get DNSSEC which would prevent the greatest threats, hijacking and injection.
There is virtually no DNSSEC deployed on any major sites on the Internet and, because DNSSEC is a terrible protocol, it's unlikely there ever will be. I'm a broken record on this; you can just search "author:tptacek DNSSEC" in the bar below to get lots of different reasons why.
The most important thing for this thread though is that DNSSEC provides zero privacy and, in ordinary deployments (where you talk to a nameserver rather than directly running on on your computer) no protection against injection between you and your nameserver.
I don't think DNSSEC itself is likely to ever win. But it does have an additional dimension that makes it a better foundation for privacy than DoH. DoH is strictly transport layer security, meaning it still relies on a trusted third party (Mozilla or Google or whomever) to not vacuum your requests. Whereas if records are signed, they can be sent laterally between mutually untrusting peers, including bulk broadcasts, etc.
A better foundation for privacy? No. DNSSEC provides literally no privacy. It doesn't encrypt, it only signs. DNSSEC is passively observable by design.
For privacy, getting records signed is ultimately more long-term important than getting queries encrypted immediately. As DoH shows, bolting on transport layer security is trivial.
For example, you'd never want to set your DoH resolver to an arbitrary TOR hidden service. But there would be no problem querying DNSSEC through TOR (assuming the setup wrapped the server-server protocol in something that allowed such forwarding).
What a strange argument. If you want to argue that Tor is superior to DoH, argue that. DNSSEC has nothing to do with it. Which, of course, is obvious: DNSSEC is passively observable by design.
I'm not arguing TOR is "superior" - rather it just demonstrates a use of not needing to trust an upstream. It's also another datapoint for how easy it is to bolt on transport security.
The general principle I'm appealing to is that it's better for a protocol to be missing more-critical qualities that are easier to add later, than less-critical but harder-to-change qualities that will forever be a hindrance. Signed records make for a fundamental security property that cannot be made up for with transport security.
Another way of looking at it is that the records in DNS/DNSSEC form a higher layer protocol than the server-to-server communication. Every party in the system has to agree on the format/semantics of those data objects, whereas the server-to-server protocols can be upgraded pairwise.
I didn't claim DNSSEC was good, but it is available and serves to at least verify the communication with the root servers. That is the main reason I think using the root servers is superior to your ISPs. And I thought the context was a pi-hole with a recursive resolver (like unbound) configured to use the root servers using DNSSEC. In this case it would protect against hijacking... wouldn't it?
How does DNSSEC at the roots actually protect you from an attacker manipulating DNS? They'll simply target the records from the authority server for the name you're querying --- in fact, that's what they're targeting already --- which are almost certainly not signed. Isn't "trusting the roots with DNSSEC" just security theater?
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.
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.
