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

[Mike Hoskins (michoski)]

On 8/26/15, 3:55 PM, "dns-operations on behalf of Paul Vixie"
<dns-operations-bounces at dns-oarc.net on behalf of paul at redbarn.org> wrote:


>Roland Dobbins wrote:
>> On 26 Aug 2015, at 2:31, Ralf Weber 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%.
>i disagree with that claim. google's web plant runs at that speed.
>granted, the cost of holding and managing all that state is higher for a
>million-QPS TCP service than for a million-QPS UDP service, but there's
>proof that it can be done. see also akamai.

Picking nits, since it's usually done to me, Google's web plant isn't a
"server" or "normal hardware".  It's more like a super-cluster designed
for a specific task.  Ditto Akamai.

>> Nobody is thinking about this with QUIC/HTTP 2, and it looks as if
>> nobody (except us, heh) is thinking about this with the DNS, either.
>my laptop can do thousands of dns-over-http queries per second between
>two VM's. i think this is a practical solution for small-medium
>enterprise. the place it won't work is between all the world's
>authorities and all the world's recursives. but if opendns and/or
>google-dns wanted to provision dns-over-tcp (some new protocol, not
>tcp/53 or any variation on it) or dns-over-http, they could do so easily.
>
>i'm not recommending this. i don't like state. i think mark's latest
>cookie proposal adds just enough lightweight state to keep udp from
>hurting so much, and that we ought to pursue that approach. but i don't
>want us to do so in ignorance, for example, do so because we think that
>no tcp based solution could scale to millions of QPS. (because with
>enough rocket boosters, pigs CAN fly.)

Agreed, anything's possible if you throw enough resources at it (even time
travel, if the resource is time).