Yes. But that something shouldn't include sending _anything_ off the machine, which is what you suggested. If I didn't send a query to begin with, I sure in hell ought not to "re-send one" because I got a
I think you are confused here. Let me clarify. I want the A record for HOME.NETSCAPE.COM. I send a query for it to NS.MCI.NET, with the query ID "10". Immediately thereafter, I receive 15 responses, forged to appear to come from NS.MCI.NET, with IDs ranging from "20" to "65500". None of them can possibly be valid, and there's no legitimate reason that I should be receiving these responses. I (nameserver) therefore make the determination that I am under attack. At this point, I can either log the fact and ignore what's happening, in which case the attacker will simply continue to send forged responses until one of them happens to bear the query ID "10", or I can decide "hey, I'm going to ignore even a valid response from NS.MCI.NET at this point, because I have no way to tell that it isn't forged". The problem with this is that it allows a trivial denial of service attack. I'm Karl Kashpureff, and I want to prevent anyone at Netcom from being able to resolve WWW.NETSOL.COM. All I do is send a consistant stream of forged responses from the listed authority servers for NETSOL.COM to Netcom's nameservers. They will no longer be able to resolve NETSOL.COM, since every query they open up will be immediately invalidated by a fake response. What I'm saying probably makes the ID guessing attack look much simpler than it really is. This is because, in the real world, there are actual authority servers that actually receive the sent query. Even in the absence of countermeasures such as the one outlined above, brute-force ID guessing attacks are extremely difficult, since the correct ID needs to be guessed prior to the receipt of a legitimate answer by a real server. The 4.9.6 resolution to the ID-guessing problem contributes randomized query IDs to this. In the presence of randomized query IDs, and in the absence of attacks on the legitimate authority servers, it's probably reasonable to assume that DNS is reliable in the face of an attack, due to the extremely low likelihood of guessing the right one out of sixty-five thousand IDs before a valid response. However, in the presence of an attack on the legitimate authorities, we have a real problem. If I can cause all the listed authorities for a domain to cease responding to queries, I can set myself up for a completely successful spoofing attack on the records they're answering for. There's a real issue here involving the fact that, right now, /any/ denial of service attack in BIND (and we've just seen one of them posted to Bugtraq) potentially allows for the compromise of nameserver caches. A proposed countermeasure for this involves something I've taken to referring to as "DNS cookies". The goal is to ensure that the listed authority servers are capable of answering questions; that is, we'd like to know if an attacker will have to beat out a legitimate server in a brute force attack (in which case the attack will be difficult to carry out), or whether the attacker will always be successful, since the authorities can't assert the right information. The idea is to send a random nonrecursive query to the authority server being queried, in addition to (in a seperate packet) the real query. Using a second query as a cookie allows us a massive random number space; we can safely assume that the receipt of an answer for the random "cookie" query means that the listed server is alive and answering. This method would only be used when it's determined that the nameserver is under attack, and should therefore add minimal load to the DNS system. In place, the attack changes from something with deterministic chances of success (I /will/ eventually hit on the right ID) to something with a very slim probability of success (I'll eventually hit the right ID, but the likelihood of doing so before the real server answers is minimal). So, there's another piece of input. There are other ideas, too. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"