On Tuesday, 28 April 2020 01:02:27 UTC Shumon Huque wrote: > On Sat, Apr 25, 2020 at 2:57 AM Paul Vixie <p...@redbarn.org> wrote: > > ... > > The DNSSEC specs have always contemplated validating stub resolvers. > I think the Kaminsky cache poisoning scare inadvertently focussed our > efforts on solving the DNSSEC-to-RDNS problem to the exclusion of other > more complete possibilities.
stub resolvers were thrown overboard in order to get DS working. > There has certainly been work on validating stubs on the margin though: > getdns, stubby, etc, but those are only used by a small minority of tech > savvy users (as far as I'm aware). as long as the configured RDNS is DS-aware, yes. if the RDNS is older than that, and if there's a firewall preventing the stub from talking directly to authorities, there's no way for a stub to learn the DS part of the signature chain. so, a stub resolver needs a completely modern RDNS to work. this has not scaled, and won't. > The one significant impediment cited for validating stubs is the middlebox > last mile problem. Here again, there has been attempted work, e.g. the > TLS DNSSEC chain extension for TLS enabled applications. And DNS > over TLS/HTTPS could prove to be an enabler for validating stub resolvers > to obtain a clean, unmolested path to an upstream recursive service. i agree that if we change most of the rules, we can get a different outcome. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
