[dns-operations] A dns-proxy for DNS over HTTP(s)

[Shane Kerr]

Frank,

If I recall correctly ISC did some experimentation about using
unique IPv6 addresses as part of the anti-Kaminsky hardening during the
"Summer of Fear". I think that they discovered that it was impractical,
although I don't know the reasons.

My guess would probably be that OS have not really optimized to add &
remove addresses at high speeds. Possibly a server could allocate a few
hundred addresses at startup for this purpose though?

Cheers,

--
Shane

On Sun, 30 Aug 2015 00:32:29 -0500
"Frank Bulk" <frnkblk at iname.com> wrote:

> Perhaps with IPv6 a client could be given a unique address with which to
> speak to a DNS server ... that could be part of the cookie.
> 
> Frank
> 
> -----Original Message-----
> From: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] On Behalf
> Of Mark Delany
> Sent: Wednesday, August 26, 2015 4:18 PM
> To: dns-operations at dns-oarc.net; dns-operations
> <dns-operations at dns-oarc.net>
> Subject: Re: [dns-operations] A dns-proxy for DNS over HTTP(s)
> 
> On 26Aug15, Paul Vixie allegedly wrote:
> 
> > >> DNS server scale to million of requests per second on normal hardware
> > >> I have not yet heard of a web server scaling to that.
> > >
> > > Concur 100%.
> 
> > my laptop can do thousands of dns-over-http queries per second between
> 
> > i'm not recommending this. i don't like state.
> 
> Well, some sort of state is needed. The question is, what sort is
> best.
> 
> Consider: a completely idle TCP session can be expressed in a 100 byte
> tuple: 2 * (ip:port, seq:wsize, options, fudge). With appropriate OS
> support a DNS server could "collapse" the kernel and user memory cost
> of an idle socket then revivify it hours or days later when the next
> TCP packet comes in that matches the tuple.
> 
> In essence the TCP-tuple is a server-side cookie that provides enough
> information for the kernel to re-instantiate socket buffers, sequence
> numbers, timers and the like.
> 
> OS support requires three parts: 1) Collapse an idle socket to a tuple
> 2) Revivify a socket from a tuple and 3) present candidate inbound TCP
> packets that may match a tuple. (Matching could be done in an app or
> the kernel, actually.)
> 
> The instantiation cost has to be much cheaper than a full TCP setup
> and of course there is no need for a 3-way handshake.
> 
> Over time a smart auth server could profile clients to categorize them
> into keep-active, collapse and dont-bother buckets to further optimize
> state costs.
> 
> In this scenario, a busy auth may well have maybe 50,000 keep-active
> sockets and a couple of million collapsed sockets all fitting in a
> relatively modest memory footprint of, say, 20-50GB.
> 
> The incentive is aligned for a server to implement this as it improves
> delivery of their content. A less busy server without the memory just
> wouldn't bother.
> 
> Some caveats. DNS-over-HTTPS is much less amenable to this
> approach. You would not want to put such a server behind a stateful
> firewall...
> 
> 
> Mark.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>