http://pastebin.com/NKbnh8q8

can somebody confirm that this would work? why, why not?

2/15/2012 7:32:38 PM

IF WE ALL DON'T BUY GAS TOMORROW THE ASTEROID WILL DEFLECT AND GLOBAL WARMING WILL STOP BEFORE THE PILOTS CRASH.

2/15/2012 7:52:18 PM

if they were capable of taking out all the root DNS servers at once and no other cached servers could stay up, then it would be a pain. but, I doubt the other DNS servers would fail so spectacularly. ISPs, maybe, but they'd just point to someone else rather quickly and it'd be over in a few minutes

then again, giving out the tool you are going to use 40 something days ahead of time, along with your attack plan, seems to be a dumb way to go about it. Then again, it worked in Desert Storm, so whatever

[Edited on February 15, 2012 at 9:02 PM. Reason : ]

2/15/2012 9:01:50 PM

the dns roots are pretty hardened. but if you could take them down, most dns servers are gonna have the tld servers cached anyway. .com ttl is 2 days so you'd need to hold down the roots for 2 days and/or take down the .com tld servers.

even then ISP servers could probably cache the authoritive name servers for all the domains they have cached. so isps would know 216.239.32.10 is ns1.google.com which is authoritative for all of google.com. google wouldnt be able to change that nameserver, but they'd be able to change any records underneath google.com

but really its hardly worth thinking about cause the dns roots are probably impossible to kill.

2/15/2012 10:57:24 PM

The questions I had are these:

http://www.isoc.org/briefings/020/

Quote :

" Q: Does all Internet traffic pass through the root name servers? A: No Internet traffic passes through the root name servers at all. They have nothing to do with routing, note the difference in spelling. Name servers just answer queries from other parts of the DNS. Q: Are the root name servers queried every time I browse the web or send mail? A: No, information is cached in the DNS. Your computer will query a caching DNS server to resolve domain names. A well behaved DNS server needs to query the root name servers only once every 48 hours for each particular TLD. In the meantime it can resolve names for that TLD without involvement of the root name servers. Because of this caching almost all DNS queries are answered without involvement of the root name servers. Q: Who are the root name server operators? A: There currently are 12 organisations providing root name service at 13 unique IPv4 addresses. They are: A - VeriSign Global Registry Services B - University of Southern California - Information Sciences Institute C - Cogent Communications D - University of Maryland E - NASA Ames Research Center F - Internet Systems Consortium, Inc. G - U.S. DOD Network Information Center H - U.S. Army Research Lab I - Autonomica/NORDUnet J - VeriSign Global Registry Services K - RIPE NCC L - ICANN M - WIDE Project Information about most operators can be found via http://www.root-servers.org, or specifically via http://X.root-servers.org where X stands for one of the letters listed above. Q: What will happen if half of the letters will stop answering queries? A: The load will be absorbed by the remaining letters and Internet users will not notice at all. However the operational "headroom" to absorb significant load increases, whatever their cause, will be reduced. Q: Have more than half of the letters failed before? A: Many reports about a DDoS attack in October 2002 say that more than half of the root name servers were rendered unavailable for as much as an hour by the attack. Yet the reports do not agree about which of the servers were affected because it depends from where in the Internet you measure. Reports tend to list 'distant' servers as unavailable and 'close-by' servers as available. See the questions about monitoring for an explanation. All reports agree that the the attack caused no disruption of DNS service. Q: What if all root name serves would stop answering queries? A: Now you are stretching it. How likely is that? The diversity in the system will prevent that from happening. But let's treat it as a hypothetical case: In that hypothetical case the Internet will not suddenly grind to a halt. If absolutely nothing is done to correct the situation every hour about 2% of all queries will not be answered, 2% at the end of the first hour, 4% at the end of the second hour and so forth until 48h after the root name servers stop answering queries no DNS names can be resolved anymore. However it is even more hypothetical to assume that nothing will be done to correct this hypothetical situation. Q: What are realistic scenarios for root name service degradation then? A: The main concern are denial of service attacks or just plain increased load.The monthly average load of all root name servers in September 2007 is more than 118,000 queries per second (90,000 in December 2004) with regular peaks at several times the average which are handled gracefully.This is more than 10 billion (10^10) queries on average every day.These days load induced service degradations are more likely caused by network problems than by overload of the servers themselves: servers continue to answer all queries that get to them but not all queries may get there.Serious DDoS attacks can overload parts of the network infrastructure. Q: This figure seems much too high, why is that? A: Indeed the expected load from well behaved root name server clients is much lower. For each TLD they should only need to query the root name servers about once every 48 hours. In practice the majority of the present load is coming from misconfigured or broken DNS clients. There are also regular deliberate attacks on the root name servers. Since the root name server operators cannot decide which queries are 'valid' they have little choice but to answer all queries. The capacity of the system has to be designed to meet the load, whether the queries are 'valid' or not. Q: Why can't the root name server operators just drop invalid queries? A: It is impossible to decide clearly what valid queries are. Making assumptions leads down a very slippery slope ending in preferring queries from your friends. The root name server operators do not want to come near this slippery slope. Dropping queries at the server would not solve the problem of the network load these queries cause. Finally it turns out to be easier just to answer all queries than to spend resources trying to decide which ones to drop. Q: How do the root name operators meet the load challenge? A: The traditional way is to constantly upgrade both the servers themselves and their network connectivity. The K server at the LINX is currently on the fourth total replacement of hardware since 1997. Its connectivity has increased similarly. Another way of dealing with load is to use anycasting; six letters are currently anycasted. When the first version of this document was published, there were 80 locations and now there are more than 130. Q: Can you explain anycasting please? A: Having sufficient network capacity to reach the servers is a big concern under high load. One way to address this is to shorten the distance between clients and servers by distributing the servers in the network. This way queries and responses have to travel shorter distances and thus use less network resources. Potential congestion near relatively few busy servers is spread out and more servers can be effectively deployed. The number of addresses at which root name service is provided is limited to 13 by the current DNS protocol. In order to deploy servers at additional locations one has to re-use the addresses. This is done by announcing network routes, note different spelling and meaning from roots, towards the same address from all places where servers are deployed; the routing system then takes care of selecting which server receives the traffic; generally this is the one closest to the client in the network topology. Anycasting is not free, additional server instances have to be deployed and operated reliably at remote locations; management and monitoring becomes significantly more involved and expensive. Service problems are harder to diagnose because a problem has to be traced to a specific instance and often the root (pun intended) cause of a problem is in packet routing rather than operation of the server itself. Using anycast the number of operational server locations has grown from 13 in 4 countries (2002) to more than 80 in 34 countries (December 2004) and more than 130 in 53 countries in September 2007. This has made the root name server system much more resilient to denial of service attacks and has also improved service quality in many regions. Q: Is there a hierarchy or dependency between the different anycast instances of a letter? A: No there is not. If one of them fails the others will continue to operate. The remaining instances will provide service to the clients of the failed instance whenever Internet routing has changed accordingly. Until this happens these clients will be served by other letters. "

I think I'll go grab some popcorn in anticipation of March 31 ...

[Edited on February 16, 2012 at 10:14 AM. Reason : .]

2/16/2012 10:14:06 AM

Quote :

"HARMLESS OLD WOMANS"

2/16/2012 10:45:00 AM