Lutz Donnerhacke wrote on 02/16/2007 10:20:09 AM:
* Roy Arends wrote:
Lutz Donnerhacke wrote on 02/16/2007 09:24:33 AM:
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.
So use it for this.
not really. I can also validate on a stub resolver.
I wouldn't call this "stub". A stub resolver is a protocol translator: It offers an well known API to well known protocol. It does nothing more of
I just explained why I don't want to do that. the
protocol itself.
I'd call this a "security aware stub resolver" (rfc 4033, section 2).
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.
The end user has a stub resolver pointing to a trustwothy validating one. It's this plain simple. If you want to break this behavior, DNSSEC is dead.
explain to me how DNSSEC is dead by doing validation on a stub resolver.
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.
I'm responsible for DNS at an ISP: The ISP's resolver know who queries 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.
DNSSEC validating on a larger resolver does scale well, because - that's
So, what do you offer to your clients? SIG(0), TSIG, DTLS, some VPN method ? How many clients have configured that ? And with 'who queries it', you probably mean that you have some list in place somewhere that discriminates on ip. Note that I can simply passive query your resolver box. You wouldn't even know it is me. the
important observation I made - a lot of queries can be answered from cached NSEC records without querying further. The whole bunch of NXDOMAIN dropped by about 70% here. Crypto is cheap compared to networking.
I find those last two statements highly unlikely, but for argument sake, multiply this by cost(crypto(lastmile))*count(users).
Why should I trust data, validated by my ISP?
Because you choose him to do so.
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
Eh ? No, I rely on it to bring me the data. I'll validate it myself, thank you very much. trust
my ISP, while they're cashing (no typo) in on my unfortunate misspellings.
If you do not trust your ISP, you need an other one or you won validating protocols i.e. VPN to a trustwothy point.
"trust" is not a binary concept. You need to relate trust to a service, and then still, it comes in degrees. I trust my bank to process payments. I trust my ISP to keep my link alive and to have proper peering in place. I _could_ trust my ISP to serve me the right data, but that would only be the right data in their perspective, wouldn't it, and that might not match mine.
DNSSEC for end users is not a security issue, it's a deployment issue.
Eh ? DNSSEC is security backfitted on a widely deployed protocol. This has deployment issues in general. Roy