Re: Open Resolver Problems

[Mark Andrews <marka () isc org>]

In message <51530632.3020402 () 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 () 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 () isc org