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

[Paul Vixie]

long delay while i considered the matter.


Mark Delany wrote:
> On 26Aug15, Paul Vixie allegedly wrote:
>
>> i am specifically not advocating DNS-over-HTTP as anything other
>> than a DNS VPN meant to get clean DNS signal inside hotel rooms and
>> coffee shops who tamper with UDP/53.
>
> Gotcha. Our goals differ then.
>
> My point is that DNS-over-TCP/HTTP is viable at Internet scale with
> network latency characteristics similar to UDP with security
> characteristics of TCP.

i think that could work. you'd have to standardize a transform like

DNS at ADDRESS on (TCP PORT 53 OR UDP PORT 53)

becomes:

DNS over HTTP(S) at ADDRESS on TCP PORT 80 (443) at URI /DOMAIN_NAME_SERVICE

this would opportunistically try the HTTP(S) transport before falling
back to UDP/53 and perhaps TCP/53, making the assumption that if there's
an HTTP(S) listener on the standard web port at the same address, and it
understands what the /DOMAIN_NAME_SERVICE URI means, then it's the same
service by a different transport and protocol.

with persistent connections, most access-network RDNS servers could
provision enough TCP capacity for all of the local stubs. it might
require load balancers just to hold that state, in larger access
networks. whereas most ADNS servers probably will only allocate 50K or
so TCB's, and would have to reclaim less-active connections when the
pool is larger than some threshold.

where my thinking logjams is on how to handle the HTTPS protocol. i
believe that X.509 has failed, and that more than half of the CA's
listed in the browser's trusted-CA list are criminal or governmental,
presenting a gigantic risk of interception and surveillance. but using
pre-shared keys is not safe either-- any national firewall or
hotel/coffeeshop firewall can look at the clear text SSL metadata and
determine that this is not a normal HTTPS connection, and they can block
it without risk to themselves.

so, i havn't got a solution to interception and surveillance based on
DNS-over-HTTPS, so we might as well stick to DNS-over-HTTP. no need to
encourage our governments to melt the ice caps using our tax money just
to get some false sense of privacy.

the DPRIVE folks are likely going to offer a less-marginal solution to
surveillance and interception.

> The cost is of course server state, but my earlier post is trying to
> suggest that managing large amounts of TCP server state is tractable
> for the traffic profile of a large auth server.

and for the record, i agree.

-- 
Paul Vixie