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

David Conrad drc at virtualized.org
Tue May 20 19:07:35 UTC 2008


On May 20, 2008, at 11:18 AM, Paul Vixie wrote:
>> Or, you permanently lock down a set of provider independent DNS  
>> root service
>> /32s and /128s (reducing the risk of prefix hijack by someone  
>> announcing a
>> more specific) in a DNSOP BCP, allowing folks to configure filters  
>> to ensure
>> announcements for those /32s are blocked and are coming from the  
>> "correct"
>> ASes.  Figuring out how to (securely) change everyone's caching  
>> server
>> configuration remotely would no longer be an issue.
> i guess this would make earthlink's life easier.  right now if they  
> intercept
> traffic to f-root by injecting a more-specific /32 and /128 into  
> their IGP, we
> could go after them for fraud.

Who are you to say what is or is not fraud within someone's network?   
Particularly if it is not announced publicly?  If the root server  
addresses were made golden and memorialized in a BCP, you might be  
able to argue that somebody providing DNS service on one of those  
address would constitute fraud, but now?

> if there were a well known, un-owned anycast
> address for f-root, then they could just shovel their DNS traffic to  
> paxfire
> ...

People can and do do this today.  The address for F is well known by  
definition.  The only significant difference is that now, it can  
change, resulting in some caching servers getting updated and some  
not.  I'm not sure I see the big advantage here.

> i have long fought against root name server renumbering.  too many  
> clients
> never update their hints.


> it gives me no pleasure to have been proved right on may 2 2008 that  
> ep.net
> should not have had control over these addresses and that we should  
> stop doing
> any kind of renumbering of root name servers.

So why not memorialize a set of "golden" /32s and /128s in a BCP and  
be done with it?  No more root hints file.  Yay!


More information about the dns-operations mailing list