[127074] in North American Network Operators' Group
Please report issues with i.root-servers.net
daemon@ATHENA.MIT.EDU (Lindqvist Kurt Erik)
Sat Jun 12 14:28:13 2010
From: Lindqvist Kurt Erik <kurtis@kurtis.pp.se>
Date: Sat, 12 Jun 2010 20:27:40 +0200
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-10422--440166651
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
=09
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@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.=20
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.=20
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 noc@netnod.se.=20
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.=20
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.=20
---
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).=20
---
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.=20
---
Kurt Erik Lindqvist
CEO Netnod
--Apple-Mail-10422--440166651
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkwT0ZwACgkQAFdZ6xrc/t5uxwCgid1jTr4uHc3NgEsJLL+mXJt5
jr4An1Xo56sqEKl8Qj8QZe4Lf+z/jnd0
=YTiQ
-----END PGP SIGNATURE-----
--Apple-Mail-10422--440166651--
