On Mon, May 2, 2022 at 3:28 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Florian Weimer <fweimer(a)redhat.com> said:
> At least that's a solvable problem: perform DNSSEC validation (to
> prevent actual attacks) and pretend to clients that you didn't do it (to
> avoid relying on signatures which aren't policy-confiorming). DNSSEC
> supports that approach quite well for ordinary record types. It's
> different from the web, where https:// and http:// are not equivalent in
> practice for many domains, and the schema is also visible to Javascript.
A validating resolver only returns validated results to clients.
There's no "validate but pretend you didn't" mode - if you are a
validating resolver, you either return the record and NOERROR, or you
set SERVFAIL.
Different servers have some ways to override validation, typically on a
per-name basis (so when
foo.com breaks their DNSSEC but you have too
many customers that need to get to
foo.com to leave it broken). I'm not
aware of any that any policy hooks to do something similar on an
algorithm basis, and definitely not to do the validation but then
pretend you didn't. If you want to propose such behavior, you'll need
to get that upstream first (at least in BIND, Unbound, and dnsmasq).
And that behavior would also require that the underlying library be able to
expose the fact that the signature validation failed due to local policy,
so that the resolver could make use of that information.
It sounds like the proposal here would be:
* Do the validation; if it succeeds, tell the client (if they asked).
* If it fails, but due to local policy, then tell the client no validation
was attempted (if they asked).
* If it fails, but not due to local policy, then tell the client SERVFAIL.