Slashdot Mirror
Internet Backbone DDOS "Largest Ever"
wontonenigma writes "It seems that yesterday the root servers of the internet were attacked in a massive Distributed DoS manner. I mean jeeze, only 4 or 5 out of 13 survived according to the WashPost. Check out the orignal Washington Post Article here."
Article: "The Domain Name System (DNS), which converts complex Internet protocol addressing codes into the words and names that form e-mail and Web addresses, relies on the servers to tell computers around the world how to reach key Internet domains."
The "IP system" should have been fine. The DNS system, which has become an integral part of the "internet" is not decentralized as regular internet infrastructure is. Yes it is supposed to withstand a nuclear war, and yes, it would have. btw, the system worked yesterday. only 4 of 13 may have survided, but the system still ran.
We can have the internet without dns, but we cannot have dns without the internet
If you blog it...
The root DNS servers are required to go from the TLD to the actual TLD's nameservers, eg to go from ".com" to the .com root nameservers. As a result, although critical, their results are cached with very, VERY long cache timeouts (TLD DNS servers seldom change).
.su.
Thus the hour long attack was not enough to meaningfully disrupt things, as most lookups would not require querying the root, unless you were asking for some oddball TLD like
Change the attack to be several hours, or a few days, and then cache entries start to expire and people are unable to look up new domain names. But that attack would be harder to sustain, as infected/compromised machines could be removed.
It is an interesting question who or how this was achieved. THere seems to be a lot of scanning for open windows shares (Yet Another Worm? Who knows) also going on in the past couple of days, but there is no clue if it is related.
Test your net with Netalyzr
I am not an expert but surely these servers connect to the net through some sort of router/hub whatever. The servers are made to handle a lot of traffic but what about the connecting hardware. If the routers were attacked directly wouldn't the DDOS attack still be succesful without touching or alerting the dns servers themselves.
It's an interesting idea, but it doesn't quite work like that. The routers we're talking about here (I imagine that most of the root servers are on 100BT or Gigabit Ethernet LANs which then plug into one or more DS-3s [45 Mbps] or more likely OC-3s [155 Mbps]) are designed to be able to handle many, many times more traffic than the servers are. Your average Cisco 7xxx or 12xxx router is built to handle far more traffic than any given server might see. Think about it ... you generally have many servers being serviced by one router, not the other way around. Additionally, each root server is most likely connected to multiple routers (say, they're hosted at an ISP with three DS-3s to different providers and each DS-3 is plugged into a different Cisco 7500).
Also I doubt that the routers are setup to recognize any kind of attack as they are just relays between the net and the server. Possibly the attack could go on for quite some time before any one realized what was going on.
Actually, it's the other way around. Most good routers are designed to have the ability (if you enable it) to look inside of the packets that pass through them and filter out "bad" ones based on various criteria. Thus, routers are actually perfectly suited to stopping attacks like this, while servers are expected to burn their CPU cycles doing other things (yes, servers can do this sort of filtering, but they generally have something more important to do). The only real problem is that it's often very difficult to tell the "good" packets from the "bad." After all, how do you distinguish automatically between a distributed flood of HTTP malicious requests and a Slashdotting? You get the idea.
"95% of all Slashdot
DNS is hierarchical, both is naming and in server implementation. Small ISPs cache their DNS from more major providers, up until the A to J.ROOT-SERVERS.NET main Internet servers. There is in fact one critical file, but it is mirrored to the 13 root servers, and domain look-ups are cached at the ISP level. I'm not suprised most Internet users were not affected, you wouldn't be affected if several large mail servers where DDoSed would you?
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
If you want to see in gory detail what a DDOS attack looks like in relation to what NORMALLY happens to these servers, try here. Notice the really big spike. As if you could miss it.
The stats for the h.root servers are available for the time period of the attack. Seems as though the h servers were taking in close to 94Mbits/second for a while.
More links to server stats can be found at Root Servers.org and some background is available at ICANNWatch.
Sure, do an AXFR (A-record transfer) with DiG on a root server. Of course, you have to be a priviledged user--AXFR requires full-duplex TCP instead of an ordinary UDP connection, so unfortunately *.root-servers.net and *.gtld-servers.net don't allow transfers. Yet some of the international country-code TLDs (ccTLDs) allow AXFR transfers; if you wanna host .AG or whatever just do a dig axfr and you're good to go.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
Verizon gives its users 3 servers for translating numbers to names: vnsc-pri.sys.gtei.net (4.2.2.1), vnsc.bak.sys.gtei.net (4.2.2.2), vnsc-lc.sys.gtei.net (4.2.2.3), and for internal use, i-will-not-steal-service.gtei.net (4.2.2.4) Actually, an interesting note on how this is configured. Genuity (aka GTEI aka BBN Planet), who hosts these DNS resolvers, has a simple, but effective distribution system for redundancy. There are actually several servers on AS 1 that will respond as 4.2.2.1 or .2. /32 routes are sprinkled into IGP within the network to try and route requests to the "closest" server that can answer the request. If one is in trouble, simply pull the route to it, and requests route elsewhere. It's not foolproof, as a DDOS would likely come from all borders and overwhelm all of the various servers, but it's pretty effective nontheless.
RW
That's what I do with BIND9.
The DNS system provides an "MX" resource-record for handling mail exchangers. Before the MX record, to send mail one would resolve the DNS using an A record, and connect to the resulting IP address. Nowadays, *@foobar.com doesn't have to always be handled by 140.186.139.224. In fact, there is a nice system set up for prioritizing mail handlers, built into DNS's MX records:
To answer your question, you can use IP addresses. But you'll be missing out on the prioritized DNS mail system. And don't worry about this being offtopic, the article isn't that all interesting anyways--I'd rather teach someone something interesting than write lame drivel about some "backbone DDoS" that's not even a backbone DDoS. Hey, its about the structure of the Internet...
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
Correct, I know of no DNS servers, even djbdns [cr.yp.to] DNS', which restrict queries to a limited IP range as is common with SMTP. There's not really a large risk in opening up your DNS to everyone, in fact, you there are plenty of alternate DNS root servers [jerky.net].
You don't know what you are talking about. There are two different types of DNS servers: authoritative servers and recursive resolvers. djbdns comes with tinydns, an authoritative server and dnscache, a recursive resolver. The two are completely separate. BIND includes both in the same server, which is why many people are confused into thinking they are the same thing.
tinydns does not restrict queries to only certain IP addresses. However, it can return different information depending on the source address of the query. This is usually called split horizon DNS.
dnscache does have access control. You do not want just anyone to be able to query your recursive resolvers. With dnscache, you need to explicitly allow access for IP's that can query it.
There are not risks in opening your content (authoritative) DNS servers to everyone. There are risks in opening up your resolvers to everyone.
Ethernet is a physical transport, while TCP/IP is a protocol. In fact, TCP (transmission control protocol) sits on top of IP (internet protocl). There is also UDP on top of IP (but no one says UDP/IP that I've ever heard) and ICMP on IP. UDP are short messages that are sent without creating a link, and ICMP is for things like Ping, tracerout, etc. You can create your own protocol and use it on the internet.
You can use any physical layer: ethernet, a modem, a cell phone, wifi, bluetooth, firewire, USB, power lines, etc with IP, and similarly you can use may other protocols with Ethernet or any other link Such as IPX, NetBui, Apple talk, etc.
TCP, UDP, and ICMP are tied to IP and wont work with anything else.
Then there are higher level protocols that sit on top of TCP or UDP, for example DNS sits on UDP, FTP, telnet, gnutella and others sit on TCP. Interestingly HTTP should work on other protocols as long as you can establish a link between a server and a host on it. And you have software that implements it on these other links.
There's also Ipv6, which is a newer version of IP.
Lonely?
Find love on the internet
Only if you're running older versions of BIND. Current versions of BIND can be easily chroot jailed and run as a user that isn't root (even the old, vulnerable versions could be run as non-root - a lot of the problem is that RedHat 6 installed BIND by default running as root).
The root servers run BIND.
Oolite: Elite-like game. For Mac, Linux and Windows