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

Mark Delany x2t at foxtrot.emu.st
Wed Aug 26 21:17:48 UTC 2015

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

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


More information about the dns-operations mailing list