These don’t prevent censorship necessarily, they will give you a way to detect it at best.

DNSSEC gives you the ability to verify the DNS response. It doesn’t protect against a straight up packet sniffer or ISP tampering, it just allows you to detect that it has happened.

DoT/DoH are better, they will guarantee you receive the response the resolver wanted you to. And this will prevent ISP-level blocks. But the government can just pressure public resolvers to enact the changes at the public resolver level (as they are now doing in certain European countries).

You can use your own recursive, and this will actually circumvent most censorship (but not hijacking).

Hijacking is actually quite rare. ISPs are usually implementing the blocks at their resolver (or the government is mandating that public resolvers do). To actually block things more predictably, SNI is already very prevalent and generally a better ROI (because you need to have a packet sniffer to do either).

▲

jeroenhd 4 days ago | parent [-]

DNSSEC itself won't help you alone, but the combination of DNSSEC + ODoH/DoT will. Without DNSSEC, your (O)DoH/DoT server can mess with the DNS results as much as your ISP could.

Of course you will need to configure your DNS server/client to do local validation for this, and at most it'll prevent you from falling for scams or other domain foolery.

▲

tptacek 4 days ago | parent [-]

In practice, DNSSEC won't do anything for ordinary Internet users, because it runs between recursive resolvers and authority servers, and ordinary users run neither: they use stub resolvers (essentially, "gethostbyname") --- which is why you DHCP-configure a DNS server when you connect to a network. If you were running a recursive resolver, your DNS server would just be "127.0.0.1".

The parent comment is also correct that the best DNSSEC can do for you, in the case where you're not relying on an upstream DNS server for resolution (in which case your ISP can invisibly defeat DNSSEC) is to tell you that a name has been censored.

And, of course, only a tiny fraction of zones on the Internet are signed, and most of them are irrelevant; the signature rate in the Tranco Top 1000 (which includes most popular names in European areas where DNSSEC is enabled by default and security-theatrically keyed by registrars) is below 10%.

DNS-over-HTTPS, on the other hand, does decisively solve this problem --- it allows you to delegate requests to an off-network resolver your ISP doesn't control, and, unlike with DNSSEC, the channel between you and that resolver is end-to-end secure. It also doesn't require anybody to sign their zone, and has never blown up and taken a huge popular site off the Internet for hours at a time, like DNSSEC has.

Whatever else DNSSEC is, it isn't really a solution for the censorship problem.

▲

jeroenhd 2 days ago | parent [-]

Obviously you need to enable local verification for DNSSEC to do anything in the first place, otherwise the DNS server can just lie about the DNSSEC status. If someone is manually configuring a DoH resolver, they probably have a toggle to do DNSSEC validation nearby.

DNSSEC doesn't prevent censorship, but it does make tampering obvious. Moving the point of trust from my ISP to Cloudflare doesn't solve any problems, Cloudflare still has to comply with national law. DoH is what you use to bypass censorship; DNSSEC is what you use to trust these random DNS servers you find on lists on Github somewhere.

A bit over half the websites I visit use signed zones. All banking and government websites I interact with use it. Foreign websites (especially American ones) don't, but because of the ongoing geopolitical bullshit, American websites are tough to trust even when nobody is meddling with my connection, so I'm not losing much there. That's n=1 and Americans will definitely not benefit because of poor adoption, but that only proves how much different kinds of "normal internet user" there are.

	▲	tptacek 2 days ago \| parent [-]
		I think we're basically on the same page. With respect to who is or isn't signed, I threw this together so we could stop arguing about it in the abstract on HN: https://dnssecmenot.fly.dev/