> On 28 Apr 2020, at 14:06, Paul Vixie <p...@redbarn.org> wrote: > > 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.
More correctly there isn’t protocol work to do to get stub resolvers and DNSSEC working. It just requires vendors to *implement* DNSSEC in the stub resolver or even in the application. You can take a BIND 4 resolver library and get DNSSEC working on top of it. >> 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 RDNS needs to be DNSSEC aware as you can’t get RRSIGs that match the answer, NSEC, or NSEC3 records without that, much the same as you can’t point a validating recursive server at a non-validating forwarder and have DNSSEC work reliably. >> 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
