"[...] Since dnsmasq defaults to strict DNSSEC validation, it rejects those invalid DNS entries,
and therefore the test completely fails.
That's not so much "strict" but just how DNSSEC is supposed to work.
Your Unbound "works" because it simply ignores unsigned replies from a signed zone...
Which is another way of saying "strict" like above ???
Which means
it's doing zero to protect you against DNS hijacking. Any hijacking could simply NOT sign the fake
DNS zone, and you would never even know.
This is wrong. For a known signed zone with a parental delegation, any
proper implementation of a DNS resolver will drop DNS answers that are
missing the signature records.
A "hijacked zone" with DNS answers that miss the RRSIG signature records
will be ignored. If no proper RRSIG records are received, a proper
implementation like unbound (and dnsmasq) return ServFail. the DNSSEC
status for this is called INDETERMINATE (as in, answers where withheld,
so we cannot validate the result, so we cannot answer)
Dnsmasq's strict validation is the way proper DNSSEC is meant to work, if you want DNSSEC to truly
be an effective protection mechanism.”
That's the same for unbound. I have no idea what the quoted poster
means, but their statements are self-contradicitng and wrong.
1. Is this true for unbound 1.9.x, i.e. unbound ignores unsigned replies from a DNSSEC-signed
zone? Or was this the case only in older versions of unbound? If yes, what version fixed it?
Of course unsigned responses are dropped if the parental record stated
you needed to expect signed answers from a certain key.
2. How about strict (vs. opportunistic) DNSSEC validation in current unbound 1.9.x? Is there such
a feature? Is strict DNSSEC validation available in unbound?
There is no "non-strict" mode in DNSSEC. Think about it, being
"unstrict" means the same as offering no DNSSEC at all, if it means
that anyone could spoof anything.
Paul
ps. systemd-resolved does have a broken "feature" where it uses the
first signed or unsigned answer it received, and used to not check
if the first unsigned response to come in should have been signed. I'm
not sure if that is still the case.
