All,Renesys has since a few days had a blog post at http://www.renesys.com/blog/2010/06/two-strikes-i-root.shtml. On the 9th I urged them to provide us with any data if they are seeing incorrect responses from NAY i.root-servers.net instance, and share that with n...@netnod.se. I have so far received a single email from Renesys on friday morning CET time. That email did not contain any data or further information. I asked to share that email with the Nanog list as Renesys will apparently share some results on studies of the i.root-servers.net in Beijing. I have no insight into what these findings, and Renesys did not respond to my request to see them before hand. As of today Renesys have updated their blog post with data that seems to indicate that they have seen incorrect responses from an i.root-servers.net instance. This is the first report of such responses since we re-activated our anycast node in Beijing, and we only saw this by monitoring the comments field to he blog post. At the time of re-activating the node we did test from all locations we could find and queried the i.root-servers.net node in Beijing, and we did not see any incorrect responses. Now, I would request that you all *please* report operational issues with i.root-servers.netm or in case you see any behavior you do not expect to n...@netnod.se. Unfortunately noone from us will attend the upcoming Nanog meeting, and I can't from the agenda see when the presentation is due. I am happy to answer any questions directly though, and I will try and read Renesys results as soon as they are published. In the mean time, as we are dealing what is potentially an operational problem, please report any issues to us. To provide some background, I will share some of my responses to the Renesys email on friday - although I admit they are taken out of context I think they do provide some general background information that might be worth sharing. --- As I wrote in my response to your blogpost, the node in China has ALWAYS been globally reachable (what ever that means. In our terminology it means we are not exporting the prefixes with no-export, so the prefixes propagates as far as our peers advertise them). --- As to the above, many countries tamper with DNS responses so I have no way of assuring anyone that a packet that traverses many countries, many regulations and many networks owners are ever tampered with. In the case where queries to our node in Beijing was seen to respond with incorrect responses, we have obviously been in discussions with our hosts for the node in Beijing and they have as we understand it been in discussions with many of the networks in China. What we understand from these discussions, the occurrence of these incorrect responses for queries sent to i.root-servers.net was a mistake. I have no insight into why or how the mistake happened, but we have been assured it won't be possible for it to happen again. That said - let me again stress that neither we nor anyone else, can assure that packets on the Internet does not get tampered with along the path. What we can do is to deploy mechanisms that will detect this tampering at the application layer, for example DNSSEC. --- Kurt Erik Lindqvist CEO Netnod
PGP.sig
Description: This is a digitally signed message part
