[dns-operations] we may finally have a dnssec use case ; -) Re: Odd behaviour of DNS queries in PRC (facebook, youtube & twitter)

[Phil Pennock]

On 2010-03-25 at 20:54 +0100, bert hubert wrote:
> Given the nature of why this is happening, this is one of the first usecases
> I see for DNSSEC that actually is worth the administrative overhead. 

Scenario:
 * I wish to censor the net
 * I can force people to accept my route advertisements, within a given
   geographic area
 * I can read a zonefile, so I know which 13 IP addresses I need to
   advertise and have preferred

I publish a root zone.
 (a) I leave out DNSSEC; resolution works as it does now, all the DNSSEC
     won't save anyone because it's never activated
 (b) I wish to also deal with people who have DNSSEC mandated on, so I
     publish my own DNSSEC keys, which sign the "right" keys for some
     zones and my own, second, keys for some others.  Those others then
     sign my own replacement data.  I can handle any queries needed; I
     farm out the NS servers for the faked domains across a pool of
     special auth servers which can query the correct data (where I'm
     passing through) and supplying replacement RRSIGs with my own keys.

If I can control all the roots, then DNSSEC buys you just a false sense
of security.

If a client is using a DNS recursor which learns which servers have the
lowest latency and I can provide those, reliably, I only need to control
a sub-set.  Especially if the routes are stable.

The only people protected here by DNSSEC are some who are normally just
outside my sphere of influence, who have sufficiently unstable routing
that I can't say they'll deterministically use my servers.


That's ... perhaps a non-trivial percentage of the population who you're
protecting, but not a huge win either.


Control the roots, control the data.

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20100325/1b6fb68f/attachment.sig>