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

[Frank Bulk]

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