Ted Lemon wrote:
On Apr 4, 2018, at 1:23 PM, Paul Vixie <p...@redbarn.org
<mailto:p...@redbarn.org>> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
