[prev in list] [next in list] [prev in thread] [next in thread] 

List:       djbdns
Subject:    managed DNS daydream continues
From:       "David Nicol" <davidnicol () gmail ! com>
Date:       2008-08-26 15:46:59
Message-ID: 934f64a20808260846p669a34d9i8ecc59c8054505b9 () mail ! gmail ! com
[Download RAW message or body]

On Tue, Aug 26, 2008 at 1:25 AM, Tobias Reckhard
<tobias.reckhard@secunet.com> wrote:
> David Nicol wrote the following on 25.08.2008 17:09:
>>  A "new managed DNS" that uses TLS between resolvers and
>> caches would reduce the available attack points, but would make the
>> remaining attack points more attractive.
>
> But Kaminsky's attack works by sending spoofed _authoritative_ responses
> to a DNS proxy server, it does not involve the stretch between the
> resolvers and the caches, i.e. DNS proxy servers. Hence, securing that
> stretch won't help to defend against Kaminsky's attack at all.

but the network on the main outer proxy can be tightly monitored,
multiply connected, and so on, with whatever the BCP techniques
against The Big Spoof are.

> The root servers might, there are only thirteen of them, so their
> certificates could well be published and managed. Probably even most of
> the TLD content servers could be equipped with certificates. After that,
> though, I don't think it's manageable. I mean, take a look at the dismal
> state of the DNS of many second-level domains, their operators already
> don't understand DNS basics, how are they supposed to be able to cope
> with PKI? Especially when it's got to do with 'that pesky DNS'.

so the dismal fringe dns servers would remain vulnerable.  It isn't
possible to mandate overnight change, the best that can be done is to
describe a path.

>>  "Security threat" is generally percieved to be on
>> the hotter end of  the available fires-to-put-out spectrum.
>>
>> stunnel on 5353 would work.
>
> AFAIK, stunnel can't forward UDP. OpenVPN or a somewhat trimmed down
> form of it would work, though. Technically, that is.

I was not suggesting that stunnel would forward UDP, I was suggesting
it as the least-configuration way to get DNS/TCP into DNS/SSL.  a VPN
was the initially proposed encryption layer; with "securer" DNS being
one of the various benefits to subscribing to a VPN service, along
with access to better torrent servers or whatever.

> Note that we haven't even begun to touch on the performance issues.
> Publishing a thousand precomputed signatures a second is much less work
> than having to set up a thousand RSA-and-Diffie-Hellman-secured network
> connections in the same time..

yes, stunnel is a straw man here.  A vpn uses persistent sessions; a
secured DNS network would use persistent connections to/from the
forwarding resolvers "up" to authority for all resolution traffic,
which would probably no longer be DNS, as such, at a bitfield level.
Given some adoption, security-sensitive internet services would want
to have their DNS mirrored from behind the curtain instead of
vulnerable to attack.  With a single central authority, a lot of the
multiplexing issues just go away.  On a tightly managed network, a lot
of bogus spoof packets should stand out like a sore thumb, for prompt
amputatation.
[prev in list] [next in list] [prev in thread] [next in thread]