A sad lesson from a few years of operating local
#DNS resolvers in my infrastructure -
#DNSSEC validation requires enormous resources to work reliably due to vast extra records it needs to pull from DNS for each validation and required computing power.
Forget about DNSSEC validation in systemd-resolved, dnsmasq or unbound on home routers, it will just cause periodic and apparently unexplained delays and choke overall DNS resolution.
On firewalls like
#OPNsense it also would work only server-class devices, any of the desktop-class fanless hardware won’t work reliably for DNSSEC validation even if they can perfectly handle production-class proxy and firewall traffic.
Probably what only makes sense is a dedicated Unbound validation server, a separate container or jail but running within a proper hardware server with tons of memory and CPU. But then I found out that it’s much easier to use non-DNSSEC caching resolvers on perimeter devices that forward queries to Quad9 ECS resolvers[^1] which already do DNSSEC validation.
The only missing bit is that I think my local resolvers don’t forward the DO bit downstream, but that I need to still check.
[^1]:
https://quad9.net/service/service-addresses-and-features/#ecssec
