Slashdot Mirror

← Back to Stories (view on slashdot.org)

Chinese Root Server Shut Down After DNS Problem

Posted by timothy on from the need-a-new-source-of-ginseng dept.

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."

12 of 91 comments (clear)

  1. Google Fights Back by JackieBrown · · Score: 4, Funny

    It had to happen sooner or later...

  2. So I guess you could say... by Anonymous Coward · · Score: 5, Funny

    They got to the "Root" of the problem.

    [ducks]

    1. Re:So I guess you could say... by VanessaE · · Score: 2

      Yes, but they had to...ahem...route around for a solution.

  3. Re:Calling it now by TheDarAve · · Score: 4, Funny

    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!"

  4. What happened? by jbb999 · · Score: 2, Interesting

    All of the articles I've read about this seem to confuse DNS and BGP. My guess is that the IP of one of the root dns servers was being "hijacked" by the Chinese by announcing a route to it and that route was being picked up externally so some people thinking they were using the real dns root were being diverted a chinese root server giving out different IP addresses for lookups on these domains. Does that make sense?

    1. Re:What happened? by mysticalreaper · · Score: 5, Informative

      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

  5. Re:route announcements? by pv2b · · Score: 5, Informative

    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.

  6. Re:Australia impacted too, not just Chile by fremean · · Score: 2, Informative

    Actually, that does explain a lot of things - all through march I was having issues with Twitter on my Virgin connection yet I could ssh home to my Internode connection and twidge to my hearts content... I complained but they couldn't see a problem (they probably weren't using their own dns servers)

  7. I blame American ISP's by ironicsky · · Score: 3, Insightful

    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?

    1. Re:I blame American ISP's by mysticalreaper · · Score: 3, Insightful

      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.

  8. Re:Heads should roll by mysticalreaper · · Score: 3, Insightful

    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?

  9. Re:Even more reason by PhrstBrn · · Score: 4, Informative

    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