[dns-operations] renesys blog: Identity Theft Hits the Root Name Servers

Edward Lewis Ed.Lewis at neustar.biz
Wed May 21 14:22:27 UTC 2008


At 14:14 +0200 5/21/08, Shane Kerr wrote:

>Clients don't have any trusted way to update root name server addresses.
>If they did, then they could use that.
>
>Looking up [a-m].root-servers.net using DNSSEC would seem to provide
>a mechanism to do that using existing technology.
>
>Root name servers change IP addresses now and then. Why not do a really,
>really easy thing that will make this more secure in the future?

The answer to the last question is "of course we should do that." 
But DNSSEC is not the "easy thing" that will accomplish this.  In 
fact, DNSSEC is not even the "hard" thing that would accomplish this.

Here's the scenario as I imagine it.  (Sometimes the disagreement is 
caught in the set up of the problem.)

You have a device with the 13 root server addresses configured in it, 
and we assume it is not easy to modify them.  As in, the device is 
embedded or ill managed or some other reason.  Assuming that the 
device is also able to use DNSSEC to validate the 13 name server 
addresses, then there must be a public key, perhaps for the root, or 
a specific one for verifying the root hints.

The verifying key, the public one, has to be also configured - the 
assumption is that if the operator isn't managing the root hints, 
they are also not managing the crypto-goop.

Assuming that the change of an address is a rare event, we measure 
the the "mean time between events" in years (not months).  This time 
will likely be longer than the lifetime of any public key with the 
importance of "protecting" the root zone or root hints.

The problem of long-term protection for equipment that is pretty much 
shelved and then turned on has been studied, I don't have references, 
but I know not much progress has been made from the conversations 
held.  This situation (unmanaged but operating devices) is a case of 
the same type.

So, if we protect the root hints with signatures and plan to use keys 
that roll, how do you roll the keys if you are already assuming the 
hints are not also "rolled (in the client)?"  (And this will not 
reach into the multitude of already deployed devices nor 
implementations that eschew DNSSEC today.)

I'm not against doing DNSSEC per se.  But the expense and risk of its 
deployment are only worth it if it (at least) solves the problem.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.



More information about the dns-operations mailing list