Is your feature request related to a problem? Please describe.
Local stub should always forward DNSSEC enabled queries (with DO flag) to upstream, regardless of DNSSEC validation settings. In current defaults with DNSSEC=no, DO flag is never forwarded to upstream with this setting, therefore DNSSEC reply never arrives. I think locally validation application (delv) should be able to try validation regardless validation settings in resolved.

Describe the solution you'd like
When local stub receives query with DO flag, it should always forward DO flag query to forwarders. Whether they do respond with DNSSEC records or not, it is only a problem of client application. resolved just has to cache also RRSIG, NSEC and NSEC3 records if they were received, but do not try to validate them in case of DNSSEC=no. If local DO enables queries should be squashed to non-DO queries forwarded, I think that should be different DNSSEC setting. For example DNSSEC=downgrade.

resolved should upgrade cached to DNSSEC enabled query, if previous cached response were requested without DO bit, but query does have it set. Ie dig @127.0.0.53 followed by dig +dnssec 127.0.0.53 should deliver RRSIG, if current forwarder is able to provide it.

Describe alternatives you've considered
DNSSEC=yes works fine and default DNSSEC=allow-downgrade should work fine too. Sadly DNSSEC=no is default on Fedora 34, so recent improvement is not enabled by default(rhbz). I think it should work by default and local application should be allowed to detect DNSSEC problems themselves.

As an alternative, better detection of allow-downgrade might be used, so DNSSEC=no is not used by distributions anymore. But even then this feature would make sense.

The systemd version you checked that didn't have the feature you are asking for
systemd-248~rc4-4.fc35.x86_64