DNS Amplification Attacks... and a trivial proposal

Ronald F. Guilmette rfg at tristatelogic.com
Thu Jun 13 05:31:47 UTC 2013

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:


which links to and points out a number of apparent flaws in this proposal:


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

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.


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.

More information about the bind-users mailing list