[DNSOP] DNSSEC corner case -- (surfaced by homenet vs stub validators)

[Brian Dickson <[e-mail]>]

I have looked at the need for unsigned delegations required to satisfy stub
validators, and am interested in feedback to an idea I have: signal to the
stub, deliberate non-use of DNSSEC.

The presumption is that a stub's use of a recursive resolver involves some
degree of "trust", at least if it uses the resolver by choice, and does not
set the CD bit.

What seems to be "missing" (as in, maybe it is a corner case that wasn't
noticed before), is the ability for a security-aware resolver to "signal"
to a stub, that it is deliberately not returning DNSSEC records, even
though the stub set the DO bit (DO=1).

The obvious signaling mechanism, at least to me, would be setting DO=0 in
the response.

The particular circumstances under which a resolver might do so, are
probably irrelevant (call it "local policy"), but one example in particular
would be homenet.

If a query for <something>.<homenet-domain> from a validating stub were
received, and local policy was "no DNSSEC for you" if the query is at or
below <homenet-domain>, this signaling would help the stub realize that the
situation for that resolver is, "I'm not deaf, I'm ignoring you". Set DO=0
and return unsigned answers.

Or is it far too late to be suggesting changes for sub-resolver DNSSEC
signaling?

Thoughts?
Brian