[dns-operations] Odd behaviour on one node in I root-server (facebook, youtube & twitter)

Lindqvist Kurt Erik kurtis at kurtis.pp.se
Wed Mar 31 06:27:51 UTC 2010

On 26 mar 2010, at 03.23, Lindqvist Kurt Erik wrote:

> On 25 mar 2010, at 01.17, Lindqvist Kurt Erik wrote:
>> On 24 mar 2010, at 21.04, Lars-Johan Liman wrote:
>>> mave at nic.cl:
>>>> A local ISP has told us that there's some strange behavior with at
>>>> least one ...
>>> Just FYI, we are investigating this.
>> I just wanted to clarify one thing. At Netnod/Autonomica we are completely dedicated to serving the IANA root zone as we receive it. We do not intercept, interfere, rewrite or otherwise alter either queries, responses or the content of the zone itself. 
> In order to address some speculations, I wanted to provide a public update on this. We are still investigating this issue together with the local hosting provider and their upstreams. Pending this investigation, we have withdrawn the route announcements from one of our anycast nodes for i.root-servers.net. 

In a follow up to this, we have issued the following statement 

As operators of i.root-servers.net, one of Internet's 13 DNS root
server systems, we would like to make the following statement
regarding the incident on March 24, where queries to the
i.root-servers.net instance in Beijing regarding certain domain names,
in some cases ostensibly produced incorrect responses.

*) Netnod/Autonomica is 100% committed to serving the root zone DNS
data as published by the IANA. We have made a clear and public
declaration of this, and we guarantee that the responses sent out
by any i.root-servers.net instance consist of the appropriate data
in the IANA root zone.

Furthermore, the identity of the source of the query does not in
any way affect the way a certain query is treated by


There was no deviation on our part from this principle on March 24.

*) Once we had determined that the incorrect replies were associated with
 queries sent to our anycast node in Beijing, and we had performed some testing, we
withdrew the announcements of the i.root-servers.net service from
that location. That withdrawal remains in effect.

*) Our root server instance in Beijing, China, has *NO* special
properties that makes it different from any other instance of
i.root-servers.net. For every query it receives, a response is sent
out - a response that contains exactly the same data that any other
instance of i.root-servers.net would send out in response to the
same question.

*) We see no traces what so ever of non-Netnod/Autonomica activities on our
machines in Beijing, nor do we see any traces of malfunctioning
hardware or software on said machines.

*) As packets traverse the Internet they cross multiple service
providers, that all have access to the packets. It's impossible for
a sender to guarantee that a packet arrives as sent unless some
sort of packet content integrity mechanism is applied. In the case of DNS,
this is called DNSSEC. Had the responses to the queries been signed
with DNSSEC, and had the DNSSEC protocol been observed in the
recipient end, it would have been obvious to the recipient that the
data received was not the data published by the zone maintainers.

We also note that the use of authenticated network resource public
key infrastructure systems (RPKI) would not have helped in this
situation, as we have no reason to believe that any ISP has sent
incorrect routing information to any other ISP in this case.

We would also like to stress that the incorrect responses were ONLY
seen in response to some (but not all) queries sent towards the
i.root-servers.net instance in Beijing. We have no reports that
indicate problems with any other i.root-servers.net instance than

*) We are working with CNNIC, who host our installation in Beijing, to
find an explanation for the observed behaviour, and we maintain
full confidence in our host's good intentions in providing the best
of service to us and to the Internet in general.

*) We will work with CNNIC on a way to re-establish service from
Beijing in a stable and secure manner, once we know more about the
cause of the problems seen, and feel comfortable that the situation
has been rectified.

We will produce further statements as we believe we have authoritative

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: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20100331/605e5da6/attachment.sig>

More information about the dns-operations mailing list