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
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(_at_)dotat(_dot_)at> 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).
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> 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,
Ietf mailing list