Chinese Root Server Shut Down After DNS Problem 91
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."
Re:What happened? (Score:1, Informative)
No, my understanding is that BGP is used to advertise the IP of the server - they removed the route advertisement to shut the server off from the Internet but BGP wasn't actually causing the problem or compromised.
It sounds like traffic OUT of the server was being modified in some way, I would doubt the data stored on the server had been modified as that probably flows over a secure connection but actual responses are public communications and the Chinese systems are likely filtering/modifying those so that when you try to visit twitter (or somesuch) it redirects you to a "sorry this page does not exist" site.
Re:route announcements? (Score:5, Informative)
Here's a graph of the network structure as seen by BGP. [robtex.com]
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.
Re:Australia impacted too, not just Chile (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)
Re:What happened? (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 [root-servers.org]
Re:Even more reason (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