[dns-operations] A dns-proxy for DNS over HTTP(s)
Frank Bulk
frnkblk at iname.com
Tue Sep 1 03:00:04 UTC 2015
Shane,
Thanks for the reminder -- I had forgotten about that. Isn't there a DNS
client component to this, too? If the client made a request to the main IP
address, how would it know to shift to per-client IPv6 address?
Frank
-----Original Message-----
From: Shane Kerr [mailto:shane at time-travellers.org]
Sent: Monday, August 31, 2015 1:04 AM
To: Frank Bulk <frnkblk at iname.com>
Cc: dns-operations at dns-oarc.net
Subject: Re: [dns-operations] A dns-proxy for DNS over HTTP(s)
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
>
More information about the dns-operations
mailing list