You can distribute DNS data over any transport, p2p or not. Ans with DNSSEC, you can trust the contents you get from any transport.
Are you concerned with countries forcefully removing entries? Because there are a lot of other country TLDs where you can add your entries if you want.
Virtually everyone relies on ISP DNS servers, which can trivially bypass DNSSEC (DNSSEC collapses down to a single bit in the header on the last hop from server to stub resolver). If all you're trying to do is resist DNS censorship, you can get almost everything you need from using an out-of-country name and DoH, which is universally available, very much unlike DNSSEC.
DNS without DNSSEC is pretty much vulnerable to the kind of censorship that won't even let you know you are being censored... Any name system without something equivalent to DNSSEC is.
With DNSSEC it is still vulnerable, but only to the kinds that you will know you are being censored, so you can try to get it from another country or another channel.
If your ISP denies DNSSEC for you, you already know you are being attacked, and can get it through some other channel. DoH is a cool channel, just make sure it has DNSSEC.
For the vast majority of DNSSEC-enabled end user systems, the user's device is not doing its own DNSSEC validations. It's using a DNSSEC-enabled resolver and trusting the bit set on the DNS query response where the recursive resolver says "yup, I confirm that DNSSEC is good here". Given that these resolvers are generally provided by the user's ISP, if the ISP wants to lie about DNSSEC, they can just fudge the results and set that bit to "yup, we're good".
The only way around this is for local systems to do their own recursive resolution, which isn't the default configuration on any OS or distribution that I'm aware of.
Are there any operating systems or distributions that actually ship with DNSSEC validation via local recursive resolution?
The reason I'm describing local stub resolvers that check the dnssec bit of their upstream recursive resolver is because that's how DNSSEC is implemented in every OS/distro I'm aware of. So that configuration is what actually matters when we talk about users being protected (or not) by DNSSEC.
It's an interesting flavor of "No True Scotsman" when you've managed to argue that every resolver on every OS in the world is "stupid stuff that isn't DNSSEC". If DNSSEC only works if you're using a custom fully-recursing resolver, not present on any mainstream operating system or built into a single piece of software you install on your machine, what exactly is the point of signing a zone? So far as you're concerned, nothing is doing DNSSEC validation in the first place.
DNSSEC has a very clear specification a few widespread implementations. What you are talking about fit to those?
Are you really making FUD about it, by claiming unrelated logical fallacies in a non-boolean discussion? How does a "no true Scotsman" even applies to something that has a published standard?
I know you don't like it, yet, I have never seen any proposal that brings you the assurances DNSSEC brings. AFAIK, your favorites all wither solve different problems (relevant problems, yes, but not the same) or have strictly lower assurances (AKA, they are subject to the exact same flaws, and are either worse or not better of for each one of them).
It feels like you're not as familiar with the spec as you think you are.
DNSSEC defines stub resolvers, both validating and non-validating. Validating stub resolvers do their own supplemental recursive lookups to confirm DNSSEC validation. Non-validating stub resolvers do not: they strictly determine DNSSEC trust by checking for the "ad" header bit in the response from their upstream recursive resolver.
Every operating system, Linux distribution, and application that I'm aware of defaults to having a non-validating stub resolver (if it enables DNSSEC validation at all). This renders DNSSEC validation as performed by the overwhelming majority of systems vulnerable to the risk we're flagging here.
True but in practice developers are not that creative (yet) and there are even people who are regularly creating and updating lists with all of these IPs. I manually entered them but you can also run a firewall on your mobile devices (android) as well and combined with a opnsense / pfsense at home you are pretty much set. There may come a day when a provider starts to generate tons of different DoH providers on the fly but I do not think we have seen that yet.
Probably I should figure out a way to have my pfsense box though dynamically generate the blocked IP's based on one of these dynamically updated lists...
Are you concerned with countries forcefully removing entries? Because there are a lot of other country TLDs where you can add your entries if you want.