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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
