To:
dnssec@cafax.se
From:
Miek Gieben <miekg@atoom.net>
Date:
Tue, 11 May 2004 13:47:43 +0200
Content-Disposition:
inline
In-Reply-To:
<20040510132357.GA28493@atoom.net>
Mail-Followup-To:
dnssec@cafax.se
Sender:
owner-dnssec@cafax.se
User-Agent:
Vim/Mutt/Linux
Subject:
Re: dnssec: resolver - application communication
[I'm replying to myself here, because I could't find a good sub-thread to hook this into] I think we're dealing with three issues here: 1) DNSSEC "protects" the DNS infrastructure, or maybe "cleans up" is a better word. 2) end-user security 3) debugging Ad 1: Currently (spoofing)attacks are not detected. With DNSSEC we are providing for a more secure DNS. Caching forwarders will purify the Net and filter out bad/bogus data. With secure aware caching forwarders the ISPs protect their users and greatly reduce the effect of spoofing attacks. I think this what DNSSEC aims to do on the Net: filter out bogus data. I also believe that SERVFAIL is sufficient for this. I would call this "if it's bad, it's bad". If a caching forwarder does respond (ie. no SERVFAIL) you're still not sure of anything, but the chance you get a poisoned answer is smaller. I don't believe any more that an user will disable DNSSEC if it cannot reach it's favorite website. Instead he/she will call support and ask what is the problem. It is up to the website-owner to either not secure the domain, or secure and properly maintain it. If secured and not maintained, the effect is similar to lame delegations and such. Ad 2: Some applications and end-users will want to do their own validation. They want to be sure to talk with the right party, for instance when doing on-line shopping or banking, or use the DNS to exchange IPsec or SSH key information. For those applications, security is mandatory, or the "it's only OK, when it's OK" principle: if the the validation checks out, it's OK, if not, the info is unusable. It does not matter whether the failure to validate is caused by attacks, bad administration, or due to data which is intentionally (read: verifiable) unsecured. Ad 3: David has a valid point in that you can use CD=1 and query your forwarder to debug. However if your forwarder is malicious this won't help. I believe we also need to develop debugging tools that go after the authoritative servers directly. grtz, --Miek