I understand exactly how DNSSEC works. It's been a while since I was really close to it, so I doubt I could sketch the packet formats any more, but I'm crystal clear on the structure... and I still admin it for multiple zones.

Insofar as I can extract any meaning from what you say, what you say is false. DNSSEC validation does not take place "step by step through the recursive resolution process". You seem to be conflating the resolver tree with the zone tree.

Any entity that can get access to the necessary DS, KEY, and RRSIG records (plus the actual data records) can do a complete local DNSSEC validation from the root to the leaf. It can get those records from anywhere. It doesn't even have to get all of them from the same place. It doesn't have to rely on any validation from the upstream servers, and is in a position to independently verify any validation they do do.

In fact, that's a basic DNSSEC design feature. One of the design goals was that intermediate responders didn't have to know about DNSSEC at all. Otherwise it would have been impossible to ever deploy it.

The protocol provides for asking a responder not to return invalid records, or even to return them but flag them as suspect. Clients don't have to use that functionality. Clients can always ask for all of data and for themselves. And any responder that does set any validation-related bits is expected to have verified the entire signature chain for itself, not deferred to any validation the next upstream responder claims to have done.

There's nothing "step by step" about it.

It's true that DNSSEC validation at the application end is <em>typically</em> done by a stub resolver, by which I mean a specific kind of limited DNS server that does recursive lookups and caches results for some defined population of clients, but is not authoritative for any zone. Unfortunately the word "resolver" is confusing, because it's used to refer both to stub resolvers and to more or less any software that does DNS lookups at a client, including libraries linked into application programs.

Nonetheless, the validating entity does not have to be a stub resolver or any other kind of DNS responder. It can be a "resolver" in the sense of a library, or it can be something else. Applications don't have to use the DNS protocol to talk to it, and if they do, they can do so entirely locally on a single host.

But you can still do on-endpoint validation using a stub resolver, just by using a local one that serves only applications on a single host.

To head off your next load of FUD about "running your own DNS server", such a local stub resolver is a small thing that can be installed by default, because you can get it working with zero configuration or administration, beyond maybe a forwarder address that it can get from DHCP.

Running an on-node caching resolver is nothing like running an authoritative DNS server, or even a stub resolver serving a whole network, and I know very well that you know that. Don't try to compare them.

A local resolver process doesn't demand a lot of resources by post-1990s standards, and the end user doesn't even have to know it's there. In fact, operating systems typically have similar local server processes anyway, for performance reasons. That's exactly what nscd or systemd-resolved does. Indeed, systemd-resolved, even though it was introduced for unrelated reasons, can be told to do DNSSEC validation, removing any need at all for a separate DNS-based stub resolver process.

I have trouble believing you're confused about any of this. What you're writing here, and what you've written elsewhere, sounds too much like the output of somebody trying to generate FUD that will convince the half-informed. And, yes, I did read that enormous screed you wrote a few years ago, with all the other gross, and suspiciously convenient, misunderstandings and mischaracterizations.