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

[Paul Vixie]

Mark Delany wrote:
> 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.

you mean like we described here? (and which william later codified in
RFC 6013?)


   [MSV2009]  Metzger, P., Simpson, W., and P. Vixie, "Improving TCP
              Security With Robust Cookies", Usenix ;login:, December
              2009.  http://www.usenix.org/publications/login/
              2009-12/openpdfs/metzger.pdf




> 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.

sing it, brother!

in TCPCT, we had it be that FIN was advisory, so a connection could be
restarted later and if both sides had remembered their previous
compressed connection state, then the old window size could be reused
from the get-go. this meant a single round trip to receive a reliable
multi-packet response without fear of DDoS. we thought this might have
some applicability to other protocols beyond just DNS, for example, HTTP.

later, a code point was not allocated to us, so we couldn't roll it out.

later, google reinvented this with a lot less security and called it TCPFO.

> 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...

you had me until that last part. DNS-over-HTTPS, crude and suppurating
hack that it is, would not even be aware of TCPCT under its covers.

i agree that you should never put any server behind a stateful firewall.

-- 
Paul Vixie