systemd version the issue has been seen with

244.3-1ubuntu1 / v243.7-1.fc31

Used distribution

Primarily Ubuntu 20.04, but also tested with Fedora 31

Expected behaviour you didn't see

I expect DNSSEC=yes especially to protect against MITM attacks and fail to return anything if it's signed incorrectly. This is reproducible with any DNSSEC domain - another good example is mozilla.org.

Unexpected behaviour you saw

No indication at all that validation failed

Steps to reproduce the problem

1. Pick a domain that is dnssec signed (mozilla.org/bryanquigley.com)- and confirm you have it working with:

resolvectl query bryanquigley.com
bryanquigley.com: 2606:4700:3035::6812:23a6 -- link: enp34s0
2606:4700:3030::6812:22a6 -- link: enp34s0
104.18.35.166 -- link: enp34s0
104.18.34.166 -- link: enp34s0
-- Information acquired via protocol DNS in 159.1ms.
-- Data is authenticated: yes

2. sudo resolvectl flush-caches
3. Add a DNS record on your DNS server for bryanquigley.com/mozilla.org to point to 1.0.0.0.
4. resolvectl query bryanquigley.com
   bryanquigley.com: 2606:4700:3030::6812:22a6 -- link: enp34s0
   2606:4700:3035::6812:23a6 -- link: enp34s0
   1.0.0.0 -- link: enp34s0

-- Information acquired via protocol DNS in 129.2ms.
-- Data is authenticated: no
It just reports that data is not authenticated, when I think it should fail (or just report the IPv6 bit).

The DNS server in question ( a home router in this case is doing the right thing according to delv):
Normal:
delv bryanquigley.com @192.168.254.254
; fully validated
bryanquigley.com. 300 IN A 104.18.34.166
bryanquigley.com. 300 IN A 104.18.35.166
bryanquigley.com. 300 IN RRSIG A 13 2 300 20200319200516 20200317180516 34505 bryanquigley.com. psckwes4JdpZs7rmjh3rriOXGzwNLaImx6TCHGFsaNbJeKS49YYpgwdm HTmGSm9/p/ZnRU6o8hbGg2vOTYVj4A==

MITM:
delv bryanquigley.com @192.168.254.254
;; insecurity proof failed resolving 'bryanquigley.com/A/IN': 192.168.254.254#53
;; resolution failed: insecurity proof failed