[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dns-operations
Subject:    [dns-operations] Please report any issues with i.root-servers.net
From:       kurtis () kurtis ! pp ! se (Lindqvist Kurt Erik)
Date:       2010-06-12 18:28:40
Message-ID: 5F3A4840-8605-482A-9C85-C3AE5588AD5E () kurtis ! pp ! se
[Download RAW message or body]

		

	All,


please find below an email I just sent to Nanog. I thought this might be worth \
crossposting here :

	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 noc at 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.netinstance. 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 tonoc at \
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

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://lists.dns-oarc.net/pipermail/dns-operations/attachments/20100612/2bc13b57/attachment.pgp>



[prev in list] [next in list] [prev in thread] [next in thread]