[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list