Chinese root server is shut down - DNS and censorship

[Brenden Kuerbis]

Robin,

Renesys has done the best write up of the incident:

http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml

For me, the takeaway is that root server operators could choose to not
locate root server instances in countries with govt's that censor the DNS.
Similarly, ISPs could choose not to access root server instances through
providers that are under govt pressure to censor the DNS.  Both scenarios
might help prevent "leakage" of DNS censorship (but not eliminate it), and
would probably diminish DNS availability for Internet users in censoring
countries.

A tough call for root operators/ISPs, and I think in many ways similar to
what Google considered over the past year.  In any case, I think it should
be clear here that the real problem is the government's censorship policy.

I'd like to hear what others think.


Brenden


On Mon, Mar 29, 2010 at 1:21 AM, Robin Gross <robin at ipjustice.org> wrote:

> I'd like to learn more about the implications for censorship in this recent
> episode with the Chinese root server and NIC server in Chile.    Any DNS
> experts provide any guidance?
>
> Thanks,
> Robin
>
>
> http://www.itworld.com/networking/102576/after-dns-problem-chinese-root-server-shut-down
>
> After DNS problem, Chinese root server is shut down
>
> *The server is thought to have extended Chinese filtering technology to
> Chile and the US*
> by Robert McMillan <http://www.itworld.com/node/510>
> *March 26, 2010, 08:10 PM —  *IDG News Service —
>
>
> A China-based root DNS server associated with networking problems in Chile
> and the U.S. has been disconnected from the Internet.
>
> The action by the server's operator, Netnod, appears to have resolved a
> problem that was causing some Internet sites to be inadvertently censored by
> a system set up in the People's Republic of China.
>
> On Wednesday, operators at NIC Chile noticed that several ISPs (Internet
> service providers) were providing faulty DNS information, apparently derived
> from China. China uses the DNS system to enforce Internet censorship on its
> so-called Great Firewall of China, and the ISPs were using this incorrect
> DNS information.
>
> That meant that users of the network trying to visit Facebook, Twitter and
> YouTube were directed to Chinese computers instead.
>
> In Chile, ISPs VTR, Telmex and several others -- all of them customers of
> upstream provider Global Crossing -- were affected, NIC Chile said in a
> statement<http://blogs.csoonline.com/1179/chile_nic_explains_great_firewall_incident>on Friday. The problem, first publicly reported on Wednesday, appears to
> have persisted for a few days before it was made public, the statement says.
>
> A NIC Chile server in California was also hit with the problem, NIC Chile
> said. While it's not clear how this server was getting the bad DNS
> information, it came via either Network Solutions or Equinix, according to
> NIC Chile.
>
> Network Solutions wasn't to blame as it does not offer backbone provider
> services to NIC Chile, said Rick Wilhelm, the company's vice president of
> engineering. Equinix and Global Crossing could not immediately be reached
> for comment.
>
> Netnod, which maintains a copy of its root DNS server in China, has now
> "withdrawn route announcements" made by the server, according to company CEO
> Kurt Lindqvist. This effectively disconnects the server from the Internet.
> In an e-mail interview, Lindqvist said he could not recall when his company
> took this action.
>
> Netnod insists that its server did not contain the bad data that redirected
> Internet traffic, and security experts agree, saying that its data was
> probably being altered by the Chinese government somewhere on China's
> network, in order to enforce the country's Great Firewall.
>
>
>
>
>
>
> IP JUSTICE
> Robin Gross, Executive Director
> 1192 Haight Street, San Francisco, CA  94117  USA
> p: +1-415-553-6261    f: +1-415-462-6451
> w: http://www.ipjustice.org     e: robin at ipjustice.org
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncuc.org/pipermail/ncuc-discuss/attachments/20100402/167755b1/attachment.html>