I personally have been mad as hell about DNS amplification attacks, ever since I first had the displeasure of finding myself on the business end of one back in 2003. In recent days however I've been given reason to be outraged about them all over again with the news that two organiza- tions that I have been acquainted with, URIBL and EasyDNS, have been targeted of late.
Googling on the topic today, I quicky found this: http://www.opine.me/cert-advisory-on-dns-amplification-offers-little-hope/ which links to and points out a number of apparent flaws in this proposal: http://ss.vix.com/~vixie/isc-tn-2012-1.txt but which then proceeds on to develop a proposal of the author's own, which I personally believe also suffers from some serious flaws and is likewise unlikely to yield any meaningful relief from this ongoing problem in the near term. So anyway, I have a have couple of very brief questions... 1) If everyone on the planet were to somehow magically and immediately be converted over to DNSSEC tomorrow, then would DNS amplification attacks become a thing of the past, starting tomorrow? Does DNSSEC "solve" the DNS amplification attack problem? Or does it have no direct bearing on it whatsoever? (Sorry, but I confess that I am largely ignorant about DNSSEC, so I really have no idea if there is any relation between that and DNS amplification attacks.) 2) Has anyone ever proposed adding to the DNS protocol something vaguely reminicent of the old ICMP Source Quench? If so, what became of that proposal? Regarding question #2, to be clear, what I was contemplating would be some sort of new message type, perhaps signified by using some pre-existing reserved bit combination in the DNS packet header (or maybe via a query for some special reserved name, like "bind.quench" which must be sent _only_ via TCP to be considered valid), which would say, in effect: 1) If you did not send me a DNS UDP response packet recently with the exact same ID field value as is contained in this packet, then please just ignore this message (because apparently somebody is sending me packets directly while pretending to be you). 2) If however you _did_ send me a DNS UDP response packet recently with the exact same ID field value as is contained in this packet, then please stop replying to any further DNS queries that appear to be from me and that are sent to you via UDP until further notice. (In the meantime I will send you queries only via TCP if I find that I need anything from you.) 3) From now on, and until further notice, whenever I send you a TXT CHAOS query for the domain name contained in the question section of this packet (which I will do only via TCP, remember?), please respond (via TCP, remember?) with a coded packet which will tell me the last date and time at which you last received a DNS query *via UDP* that appeared to be from me. (That will almost certainly have been a forgery sent to you in order to get you to attack me, and if I know the last time you received one of these then I can have some idea of whether the attack is currently subsiding or not.) 4) Based upon my querying of my various intermediary attackers, including you, regarding the time they each most recently received an attack packet which targeted me, I, the victim, will decide on my own when I think the time is right for me to switch back to "normal" (UDP) operations mode. When I decide that switching back to DEFCON 5 is safe, based on my own judgement and circumstances, I'll send you another specially coded DNS packet, via TCP, telling you that you may again freely respond to even UDP queries that appear to be from me (but if you don't receive one of of those "switch back to normal" messages from me within 24 hours, then switch back to normal mode communications mode with me anyway, and we will just do this dance all over again if I find that I am still being attacked at that time.) Basically, the whole idea is just simply to allow a victim to switch to "safe TCP only mode" with all of the intermediaries that are participating in the current amplification attack... and with *just* those DNS servers. This should minimize the impact that this switch to TCP-only query mode would have on all "normal" (non-attack) DNS queries... allowing those to proceed _and_ be responded to, even if some of them have to be sent to external DNS servers that are (or were) participating in a current and ongoing DNS amplification attack. When the victim decided that, in his or her own best judgement, the danger had passed, then he/she could send out the "all clear" signal, causing everything to return to normal (i.e. UDP queries from the victim would again be accepted and responded to normally, particularly and specificaly by the various DNS servers that had previously been participants in a DNS amplification attack against that specific victim. Regards, rfg P.S. Based on my understanding of DNS amplification attacks, the target/ victim should be able to tell when he's being attacked/spoofed... He'll receive one or more DNS response packets with a combination of source IP address and sequence number that simply do not match any of the queries that he himself has previously sent out and that he is still awaiting responses for. When this happens, it seems to me that it would be Nice, if he could at that point simply tell each of his (proxy) attackers to stop attacking. Does anyone disagree? P.P.S. Please note that the rather trivial scheme proposal above does not employ any kind of crytography in any way... other than the cryto- graphic methods that are nowadays routinely employed to insure a high degree of randomness for TCP packet sequence numbers. Nor would the scheme above benefit in any way from any special cryptographic methods or techniques. It just isn't needed or of any value within this rather trivial scheme. P.P.P.S. The main idea behind the above "quench" scheme is that even if careless dumbbells install their own DNS servers _and_ foolishly configure those as open recursive resolvers, as long as their DNS server software implements this "quench" protocol, then it doesn't matter even if they elect to run an open recursive resolver. Victims can still, in effect, ask to have the firehose turned off as long as the attackers keep attacking. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
