Chinese Root Server Shut Down After DNS Problem

itwbennett writes "After a networking error first reported on Wednesday last week caused computers in Chile and the US to come under the control of a system that censors the Internet in China, the 'root DNS server associated with the networking problems has been disconnected from the Internet,' writes Robert McMillan. The server's operator, Netnod, has 'withdrawn route announcements' made by the server, according to company CEO Kurt Lindqvist."

Comments

Google Fights Back

[JackieBrown]

It had to happen sooner or later...

So I guess you could say...

[Anonymous Coward]

They got to the "Root" of the problem.

[ducks]

Re:Calling it now

[TheDarAve]

Instead of Germany annexing countries to start a world war, we have China firewalling them? That'd just be an odd way to start a war... "Ha ha! Now you must go through our internet filter!"

Re:route announcements?

[pv2b]

Here's a graph of the network structure as seen by BGP.

AS29216 at the right is the AS which I.ROOT-SERVERS.NET is located in. As we can see, it is only reachable through AS8674 (NETNOD-IX).

Which in turn is reachable directly from a few different AS:es, including AS24151 (CNNIC-CRITICAL-AP).

My guess is that Netnod simply started filtering out the routes to AS29216 via AS8674 on the BGP session to AS24151.

The DNS server itself might have been using BGP, it might not have. But in the end every system on the Internet is reachable with some kind of BGP route somewhere.

I blame American ISP's

[ironicsky]

I blame American and Chile ISP's.
Why on earth would you query the root server on the other side of the world, especially in an ass backwards country like China when there are plenty of good servers here?
Shouldn't you query the closest available server, not the furthest?

Re:I blame American ISP's

[mysticalreaper]

Basically, your ideas are right. The idea is to query the closest server, for best performance. DNS data is very small, so there's not much financial concern about transmitting data across the world (which happens all the time on the internet)

Anyway, the logical routing of the internet doesn't always match the physical world. This is routine, and not a problem until DNS traffic crosses the great firewall of China, and is modified, which is what happened here.

Since this, route announcements have changed, and the Beijing server is not being queried.

But you are also correct about ISPs. ISPs can control (if they are good) which root servers are going to be queried from their network.

My overall point is that everything was operating routinely and correctly, until a new kind of DNS problem, not observed in the wild ever before, started happening. It's hard to expect the ISPs to prevent a problem they never knew would occur.

Re:Heads should roll

[mysticalreaper]

This should never have been allowed to happen in the first place, and when it had, it shouldn't have been allowed to persist for a few days before being made public and taking action.

Well i think this unreasonably harsh. No one had ever seen the great firewall of china affect DNS traffic like this in the past. So no one (not even you) was suggesting that when they set up a root DNS server in Beijing, that it would effectively send out false answers.

Now, anyone who controls a part of the network you rely on can launch a man-in-the-middle attack, which is what happened here. So to suggest that this should never have been allowed to happen, you would have to be using strong cryptography in some way. DNS has never had that mechanism--but it will soon, cause DNSSEC is coming along.The root servers are deploying it right now, and so are the other Top-level-domains.

Also, as soon as the I-root server operators realized this problem was occurring, and was outside of their control, they disabled the server. Why do you think that they sat on this problem for a few days, doing nothing about it?

Re:What happened?

[mysticalreaper]

Your suggestion makes sense, but that's not what happened.

Something like this

I.root-servers.net (beijing) -> chinese networks -> Chile networks

So, the real I root server sent correct answers to the querying computer in Chile. But, as the DNS packet travelled across the Chinese network, it was modified, and so the packet received by the Chilean network was false, returning a fake IP address for some domains, like 'facebook.com'.

This is called a 'man-in-the-middle attack'. The Chinese network, in the middle, is modifying packets.

Once the I root server operators realized this was happening, they stopped the BGP route announcement from the I root server node in Beijing, so that queries to i.root-servers.net would not be answered in Beijing, but instead by the other i-root nodes. There are 34 currently, so no problems with load would occur shutting off one node.

Hopefully that makes sense.

P.S. www.root-servers.org

Re:Even more reason

[PhrstBrn]

One small correction:

When you ask the root servers (such as a.root-servers.net) for "what is IP for www.google.com", it will respond "go ask a.gtld-servers.net". (each domain has a different server, for instance www.google.co.uk will send you to ns1.nic.uk). Asking a.gtld-servers.net will respond "go ask ns1.google.com", which will then respond with the IP of the domain, which is your answer. The chain could go further if you had "some.very.long.string.of.dots.google.com" and if each one of those nested subdomains were delegated to another DNS server (and were not contained in the zone file for "google.com").

If the answer is already cached by the DNS server and it is still within the TTL, it will just respond with the IP.

This is how a DNS caching resolver does it, your workstation is going to be configured with one of these caching resolvers. When you ask a caching resolver, it will do all these things in the background on these server, and just return the client the final answer