[dns-operations] A dns-proxy for DNS over HTTP(s)
paul at redbarn.org
Thu Aug 27 00:36:57 UTC 2015
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
> 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
[MSV2009] Metzger, P., Simpson, W., and P. Vixie, "Improving TCP
Security With Robust Cookies", Usenix ;login:, December
> 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
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.
More information about the dns-operations