Re: Multiple DNS implementations vulnerable to cache poisoning

["Steven M. Bellovin" <smb () cs columbia edu>]

On Wed, 9 Jul 2008 13:06:53 -0400
"Christopher Morrow" <morrowc.lists () gmail com> wrote:

> On Wed, Jul 9, 2008 at 12:11 PM, Steven M. Bellovin
> <smb () cs columbia edu> wrote:
> > On Wed, 9 Jul 2008 12:05:38 -0400
> > "Christopher Morrow" <morrowc.lists () 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).

Precisely my point.  (In a related vein, how many folks started
updating their OSSs a few years ago to handle IPv6 addresses?)
> > 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?
Maybe this attack will help...

More seriously -- unlike v6, the pieces here can be updated
independently; they'll then DTRT when the proper bits start showing up
on the wire.  Enterprises can sign their own zones, and give (with help
from Microsoft, of course) their employees resolvers and configurations
that know to expect signatures for that zone.  Enterprises and
consumer-facing ISPs can start deploying caching resolvers that use the
AD bit and TSIG when talking to clients.

The pressure on ICANN and down from there can happen at the same time.
Some day, they'll meet in the middle...

                --Steve Bellovin, http://www.cs.columbia.edu/~smb