Multiple DNS implementations vulnerable to cache poisoning

Wed Jul 9 17:06:53 UTC 2008

On Wed, Jul 9, 2008 at 12:11 PM, Steven M. Bellovin <smb at cs.columbia.edu> wrote:
> On Wed, 9 Jul 2008 12:05:38 -0400
> "Christopher Morrow" <morrowc.lists at gmail.com> wrote:
>> Pressure your local ICANN officers?
>>
> How many ISPs run DNS servers for customers?  Start by signing those

This is likely going to mean some mean OSS changes and perhaps
re-adjustment of where customer zones live to deal with extra load on
auth servers... Also, the customer(s) likely have to ask for that sort
of thing to happen, and include in their OSS re-signing/verifying/blah
when they make changes to their zone(s).

> zones -- that has to be done in any event.  Set up caching resolvers to
> verify signatures.  "It is not your part to finish the task, yet you

yup, more server load considerations, for services not being paid for
directly by customers... also, this is but a small minority of the
affected devices here. Not that it's not important, but there are
other parts of the dns pie. Someone mentioned CPE devices doing
cache-resolving as well, if their upstream is an affectd device they
are vulnerable, if they are vulnerable they could be subverted :(

My point was really, how do we get dns-sec rolling? From the top-down
that's 'bug icann' right? and from the bottom-up that's:

0) update applications to meaningfully use dnssec data
1) educate users/domain-owners
2) roll infrastructure to the ISP/Enterprise
3) make sure the CPE/end-systems are prepared for dnssec
4) update OSS bits down the dns-tree
5) deploy
6) rejoice?

Just saying "DNSSEC is the answer" is cool, but we've
(network/security community) been saying that for 10 years. How does
this move forward?

>
> No, I didn't say it would be easy, but if we don't start we're not
> going to get anywhere.

yup.