Recursive to stub is the piece where you need to have Apple and Microsoft provide platform integration. And they have the longest lead times. So that is the piece that you need to prioritize. If we move to a mode where most people have transitioned from ISP provided recursive DNS to some form of managed recursive DNS service, the managers of those services may employ other strategies to provide a significant improvement in DNS security even without DNSSEC adoption. One of the big fallacies of DNSSEC is the idea that providing clients access to the unfiltered authoritative DNS source is the same as securing the DNS. That was the case when DNSSEC was designed, today most endpoints would prefer to opt to connect to some sort of filtered DNS with malware and crimeware sites removed. The biggest DNS security vulnerability is in the information that is input to the DNS publication service. Most hijacking schemes have been due to attacks on registrars. On Wed, Feb 17, 2010 at 1:48 PM, Tony Finch <dot@xxxxxxxx> wrote: > On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: > >> One mechanism that was unfortunately pushed asside as a result of the >> fixation on end to end DNSSEC would be to for the resolver to use >> DNSSEC (and other methods) to authenticate the data it receives and to >> use some modification of TSIG to authenticate the communication >> between client and resolver. > > I don't think that has been pushed aside. There's not much interest in it > at the moment because the focus is on authoritative-to-recursive DNSSEC. > Maybe attention will turn to recursive-to-stub security once there is more > assurance that the recursive server's answers are authentic. > >> It would not take a great deal of effort to graft a Kerberos like scheme >> on to effect key exchange. > > Or use SIG(0). > > Tony. > -- > f.anthony.n.finch <dot@xxxxxxxx> http://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD. > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf