On Thu, Mar 30, 2017 at 07:23:46PM -0500, Brian Dickson wrote: > 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).
Why would the stub trust such a signal? Seems like an easy mechanism for a downgrade attack. > Or is it far too late to be suggesting changes for sub-resolver DNSSEC > signaling? Signaling from the resolver to the stub doesn't seem like a promising approach to me. If for some reason you can't put an insecure delegation in the global DNS, then it would work to configure both the stub and the resolver with (*sigh*) a permanent NTA for .hab.arpa or whatever. (I was so very firm in my advocacy that NTAs should always be temporary when RFC 7646 was being written. Please let's just have insecure delegations?) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
