+++ This bug was initially created as a clone of Bug #2222260 +++ Found that on upstream issue: https://github.com/systemd/systemd/issues/25676 All needed is to fake content in signed zone, reported with unbound: server: local-zone: example.org typetransparent local-data: "example.org. 3600 IN A 127.0.0.1" Reproducible: Always Steps to Reproduce: 1. Enable DNSSEC=yes 2. Run local unbound, configure fake local-data 3. Set DNS=127.0.0.1 4. resolvectl query -t example.org Actual Results: [root@rawhide ~]# resolvectl query -t a example.org example.org IN A 127.0.0.1 -- Information acquired via protocol DNS in 8.5ms. -- Data is authenticated: no; Data was acquired via local or encrypted transport: no -- Data from: network [root@rawhide ~]# resolvectl query -t aaaa example.org example.org IN AAAA 2606:2800:220:1:248:1893:25c8:1946 -- Information acquired via protocol DNS in 10.2ms. -- Data is authenticated: yes; Data was acquired via local or encrypted transport: no -- Data from: network Expected Results: Similar to when signature is present, -t a should be reported as invalid, only -t aaaa successful. Marking it with high severity, because it undermines purpose of whole DNSSEC presence.
Used just simple addition to unbound default config: # cat /etc/unbound/conf.d/bogus.conf server: local-zone: example.org typetransparent local-data: "example.org. 3600 IN A 127.0.0.1" # systemctl restart unbound # resolvectl dnssec eth0 yes # resolvectl dns eth0 127.0.0.1 # resolvectl query --validate=yes -t a example.org example.org IN A 127.0.0.1 -- Information acquired via protocol DNS in 1.9ms. -- Data is authenticated: no; Data was acquired via local or encrypted transport: no -- Data from: network
It turned out this problem was reported first on March 2020: https://github.com/systemd/systemd/issues/15158