Lutz Donnerhacke wrote on 02/16/2007 09:24:33 AM:
* Roy Arends wrote:
Note that with end user validation, and well established methods to update the end users' certificate store, we might be well on our way.
See also: http://dnss.ec/blog/?p=10
IBTD.
Please don't beg.
You can run a caching validating on your own system.
Isn't that what I was saying ? I just don't want to do all the recursion. My ISP's resolver can do that.
If you do not want this, you have to use a stub resolver. A stub resolver means, that you have a established link to an authenitcated resolver. This resolver has to do the DNSSEC validation.
not really. I can also validate on a stub resolver.
If your application want's to validate DNSSEC itself, ther exists a request format to get the responses unvalidated.
Yeah, I think I've read that in some internet draft somewhere.
Following this proposal in the blog, DNSSEC is dead.
Tell me Lutz, how does joe end user run a full featured validating resolver daemon, when he barely understand the concept of DNS. If he shouldn't run this, how does he setup "a established link to an authenticated resolver". You're not really referring to just an bunch of addresses in some resolv.conf or equivalent, since thats hardly an established link. The ISP's resolver hardly knows who's talking to it. Now, lets assume for a sec we don't run into scaling issues, since the "authenticated resolver" needs to do some crypto for the "established link", while doing some crypto to validate messages. Why should I trust data, validated by my ISP ? Them ISPs route me to a search page, while I should've received an NXDOMAIN. but, no fear, the 'ad' bit is set, and I can just blindly trust my ISP, while they're cashing (no typo) in on my unfortunate misspellings. Roy