Regarding
https://rootcanary.org/test.html test behavior.
Browser tries to resolve secure.dNaNnN.rootcanary.net & bogus.dNaNnN.rootcanary.net domains.
After that, following happen:
1. If bogus.* was resolved - test concludes resolver doesn't validate answers (yellow)
2. If bogus.* was not resolved but secure.* was - test concludes resolver performs validation. (green)
3. If bogus.* was not resolved and secure.* was not too - test concludes resolver doesn;t support algo in general. (red)
So, if upstream DNS performs validation on its own (i.e cloudflare) - bogus.* requests will not be validated upstream and therefore will not be replied to dnsmasq, and in turn - to client too.
Therefore test will be unable to test dnsmasq against 1st case at all (dnsmasq / client have no bogus.* reply), instead it actually will be test of upstream DNS server.
With cases 2 / 3 cases still possible, result will likely be between "green" (upstream and dnsmasq passes secure.* and upstream or dnsmasq blocks bogus.*) or "red" (upstream doesn't support dnssec at all or strips dnssec records badly or dnsmasq is broken somehow).
That's why you have more green than dnsmasq supports.
In clean environment there should be following - RSA-MD5/DSA*/ECC GOST algos and GOST digest are not validated (yellow), no SERVFAIL (no red), all the rest are validated (green) .
Code:
dig +dnssec <domain> @router.ip
will give a bit more light for partucular domain.
If there'll be "ad" flag - it's validated.
If no "ad" flag - insecure, due validation is not possible.
In other case validation will be failed with SERVFAIL status w/o resolved data.
Easy to check - start traffic capture with wireshark (dhcp or dhcpv6 filter) and wait for issue reproduction.[/CODE]