Open Resolver Problems

Wed Mar 27 15:20:14 UTC 2013

In message <51530632.3020402 at brightok.net>, Jack Bates writes:
> On 3/27/2013 9:34 AM, William Herrin wrote:
> > On Wed, Mar 27, 2013 at 10:00 AM, Jack Bates <jbates at brightok.net> wrote:
> >>
> >> Tracking the clients would be a huge dataset and be especially complicated
> >> in clusters. They'd be better off at detecting actual attack vectors rather
> >> than rate limiting.
> > I count this among the several reasons I intend to wait until a
> > solution has been accepted into the bind mainline.
> >
> >
> You'll also find that it serves little purpose. The only 2 methods for 
> stopping DNS amplification to my knowledge are:
> 
> 1) tcp
> 
> 2) require all requests to pad out to maximum response
> 
> 3) BCP38 (in spirit)

4) a variant of dns cookies see the draft by Donald Eastlake III
   if you can accept a couple of extra bytes in the reply to a
   non cookie query

	* minimal amplification to spoofed queries.
	* remove the need to randomise source ports.
	* state is stored in the stubs / recursives serves about
	  the upstream.
	* works with recursive servers and authoritative servers

	hash (server secret + client differentiator + time) -> crypto hash

	query
	[code = 0 (8 bits), extended id (64 bits), client differentiator (64 bits),
	 server time (32 bits), crypto hash ]

	response
	[code (8 bit), extended id (64 bits), client differentiator' (64 bits),
	 server time' (32 bits), crypto hash' ]

	A query is only accepted if the presented client differentiator
	and server time along with the server secret give the
	presented hash and not too much time has elasped otherwise
	code is set to 1 and the completed option is returned.

	clients record everything after the extended id to send with
	future queries.

	client differentiator, server time and crypto hash may be missing
	on the initial query.

> The first has latency, load, and connection limitations. It is just too 
> expensive.
> 
> The second would stop amplification, however, it will not stop botnets 
> using them in attempts to hide the bot nodes in a very effective manner. 
> It's also unlikely that we'd ever see it implemented.
> 
> The only effective fix is still BCP38 (in spirit).
> 
> 
> Jack
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org