The i-root china reroute finally makes fox news. And congress.

Wed Nov 17 14:43:31 UTC 2010

On 17 nov 2010, at 07.17, Fred Baker wrote:
> 
> 
> On Nov 17, 2010, at 1:08 AM, Suresh Ramasubramanian wrote:
> 
>> http://www.foxnews.com/politics/2010/11/16/internet-traffic-reportedly-routed-chinese-servers/
> 
> I have read the article and the list, and I'm puzzled. It's pretty clear that the root gets its records from a common source, and that the copies of them being delivered by a given root server were different. As a result, traffic intended to go place A went to place B if the TLD lookup happened to go to the particular root server in question. How did an instance of the root server find itself serving changed records? While there is no obvious indication of who made the change or for what reason, it's unlikely it was accidental.
> 
> Not sure what Glenn Beck, Fox News, or Godwin's Law have to do with it. There was a technical event that resulted in misrouting of traffic, and while international concerns regarding it had political overtones, the technical event is not a political one. If it was your traffic that had been misrouted, you might have issued expressions of concern. So why respond to it with a political response?
> 
> Sounds to me like one of the arguments for DNSSEC deployment...

Before the rumor mill get's going based on the Renesys work again, the article doesn't mention DNS, it mentions re-routing of traffic. I would like to repreat what we have said in the past. 

As best as we can tell - no i.root-servers.net instance operated by us has answered incorrectly - ever. We serve the data exactly as we receive it from IANA. 

When I read the article I assumed it referred to the routing leaks of April 8th that was also discussed on Nanog. But I haven't read the report, nor has anyone contacted us regarding it. Renesys has though, a few weeks ago contacted us to get some data from us on what happened in March. 

Best regards,

- kurtis -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20101117/9ee76013/attachment.sig>