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