ray, i won't engage on the question, should i want to do this. the
working group mantra is interoperability -- as in, if you want to do
this, here's an interoperable way. i'm not asking that the working group
ratify the intent, or recommend the method. (as went ECS.)
the proxy is transparent. we list it in resolv.conf or as a forwarder.
it regenerates the queries on the far side. it has to differentiate
between tcp and udp because the unmodified client is making strategy
decisions and implementing those using that transport choice.
this is not a service. DOH is a service. this is a proxy, which i would
like to have be interoperable. please don't ask me to change what i want
to build; that would be out-of-scope.
paul
re:
Ray Bellis wrote:
On 04/04/2018 13:20, Paul Vixie wrote:
tcp and udp are the two ways a query might have reached the
initiating proxy, and that distinction is the only thing the
responding proxy needs to know.
I disagree, I don't think that transport protocols should continue to be
used as things that should be used for policy decisions.
Per my previous message, they were a suitable proxy (no pun intended)
for "this came from an unspoofable address", or "this channel can handle
large responses" but there are other ways to achieve that now that
aren't strictly transport.
For example, presence of EDNS cookies satisfies the "unspoofable
address" and therefore would permit RRL to be skipped for that client,
but "UDP with Cookies" isn't a transport.
[I appreciate that this isn't the best example because that cookie
*might* get all the way through to the backend server anyway. But it
also might not].
if DOH becomes a standard transport, then we could add that
identifier as well -- but i don't think a client capable of DOH is
going to be using this particular proxy method.
We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on
DNS-over-QUIC too. None of those are true "transports", but server
operators may wish to make policy decisions based on the resulting
meta-properties of them.
Ray
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
