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

David Conrad drc at virtualized.org
Wed May 21 15:02:34 UTC 2008

On May 21, 2008, at 1:38 AM, Simon Waters wrote:
> On Wednesday 21 May 2008 08:53, Stephane Bortzmeyer wrote:
>> As I read it, it says "Bill Manning did something wrong".
> Bill has suggested that parts of ICANN were aware.

Bill has an interesting view of the world.  I'm told there was an  
arrangement to collect data for DITL for 48 hours some months back.   
How that translates into Bill granting CommunityDNS authorization to  
"take over L", have B serve as the distribution master for the  
CommunityDNS root server, and representing CommunityDNS's interests in  
the "root server community" is a bit of a quandary.

>> What will happen should a root name server operator start to
>> misbehave?
> Presumably ICANN will drop them from the root zone.

No.  It doesn't work like that.  ICANN does not have a policy  
mechanism to do this.

There are currently no mechanisms in place to stop a rogue root server  
operator.  Really.  The entire Internet relies on root server  
operators behaving appropriately.

If a root server operator went rogue, what would likely happen is the  
US Government (you know, the folks everyone wants to see out of any  
involvement in the Internet) would step in.

> At which point those that
> fail to update their hints will have the same issue again. If we  
> "fix" the
> root server IP addresses all it does is move the problem to the  
> routing
> layer, the nature of the problem itself doesn't change.

Actually, it does change.  Instead of having a dangling, useless for  
the rest of eternity, IP address that used to be used for root name  
service, and a requirement for every caching server on the planet to  
be updated, you have an administrative issue of how to stop one  
organization from announcing an IP address and authorizing another  
organization to start announcing an IP address.

Yes, this does push the problem to the routing system.  That's where  
RPKI comes in, but that's a different topic.

> Ultimately the issue is improved by applying cryptography to the  
> name system,


Completely unrelated.


More information about the dns-operations mailing list