Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie <[e-mail]>]

Ted Lemon wrote:
> On Apr 4, 2018, at 1:23 PM, Paul Vixie <[e-mail]
> <mailto:[e-mail]>> wrote:
>> you've cut too much context. my answer was to "just truncate". your
>> followup is about "which middlebox."
>
> Here's what I was replying to:
>
>>> For your laptop use case, why wouldn't you just have the thing running
>>> on the laptop do truncation if the answer is too long?
>>
>> that would be low fidelity. i need to run clients whose internet
>> experience will not be influenced by middleboxes.
>
> So you've said that the client's experience will be influenced by
> middleboxes.

i intended this to be heard as "will otherwise be influenced by 
middleboxes".

> I'm trying to understand what the scenario is where this
> would happen. Hence my diagram:
>
> LAPTOP<----link a---->DNS-over-https-proxy<---link b--->Full Service
> Resolver<---internet--->Authoritative servers
>
> That is, what is the problem you are trying to avoid that requires the
> proxy to transparently tunnel rather than simply answering the query?

the proxy is transparent. from https://github.com/BII-Lab/DNSoverHTTP:

> The proxy service does not interpret the DNS query or response in any
> way. It could be DNS, EDNS, or something not yet invented at the time
> of this writing. The only requirement is that each request message
> solicits exactly one response message. If anything at all goes wrong
> with the proxy service, the stub client will hear a DNS SERVFAIL
> response.

i intend that the endpoints (who are real dns speakers and listeners) be 
able to evolve, or never evolve, according to their own drumbeats.

the real middlebox that's otherwise in the way is in my hotel room or 
coffee shop, and knows that udp/53 is a service address, and 
policy-routes my dns traffic to its own agent, which thinks it knows 
what DNS has to look like, and can't handle modern (1999-era) extensions 
like EDNS.

by putting these messages inside https (a virtual high fidelity middle 
box), i make them invisible to the hotel's physical low fidelity middle 
box. and by respecting the originator's transport choice, i remain 
transparent to its strategy to use edns-512, edns-1280, tcp, dns, and so 
on, in whatever order it wants to do.

could this be done with a resolver using non-proxy DOH as a transport to 
its forwarder? sure. but that puts semantic intelligence in the middle, 
which will introduce configuration, logging, monitoring, diagnosis, 
upgrade, and patching costs. i don't want those here.

-- 
P Vixie