+1 to this. And maybe there is an outcome that doesn't need this parameter. I probably misunderstood some of the expectations people have for the parameter. With the benefit of time and sleep, it's possible that I now understand the disconnect.
My model of content-type - and by extension its parameters - is of a description of the content. However, it appears as though at least some people had different uses for the parameter: for requests, it would be an instruction/suggestion to the server to make a DNS request using the identified transport; for responses, it would be a description of where the DNS request came from. I never considered that interpretation, but - assuming that this is what it was - and the intent was to provide a means for the client to control how the server makes requests (and to see how they were made). In that case, I have a possible alternative design for the use case in the dnsop draft. Right now, DOH doesn't really say how a DNS API Server gets its responses. It could be that the API server is part of a resolver, or it could be that the DNS API Server makes a request to another resolver. But specific uses of the DOH protocol could come with additional constraints that would enable the use cases in the dnsop draft, at least as I understand them. If the goal of the dnsop draft is to extend the reach of a DNS client (note: not a DNS API client) across a network that is in some way less hostile to HTTP than it is to DNS, then I think that it can still use DOH. A DNS API server could be configured to operate in a very simple mode with no caching, just direct transposition of a request from HTTP to a request on UDP or TCP. A DNS client could be configured with two DNS API clients. Each client uses a different DNS API Server endpoint. Those endpoints would be specifically configured to use only UDP or TCP. For instance: https://use.only/tcp{?dns} would cause the server to make a request using TCP. https://use.only/udp{?dns} would cause the server to make a request using UDP. At this point, this is simple DOH, but with extra contextual information about server operation. The concerns about the requirement for HTTPS is a relevant concern. If there are cases where an unprotected HTTP connection carrying DNS is expected to traverse a network without modification where DNS encounters difficulty, maybe the dnsop draft can concentrate on that particular aspect of this. I don't think that the suggestion in DOH to use HTTP/2 is a problem; DOH permits the use of any version of HTTP. On Fri, Apr 6, 2018 at 6:53 AM, Patrick McManus <pmcma...@mozilla.com> wrote: > Hi All, > > We've had quite a thread re the -05 optional parameter to the > dns-udpwireformat registration. > > The parameter is defined as having no meaning for DoH, but was included to > accommodate a use case the dnsop wg is considering. Future proofing, if you > like. > > Upon consideration (and a read of 6838), I think including this in doh is > premature because Media Type registrations can be updated by mechanisms laid > out in RFC6838 and in this case such an update could occur without impacting > existing DoH deployments. (i.e. it does not need to be future proofed). > > Therefore the definition of the parameter should accompany the work that > makes use of it if a future standards document chooses to go down that path. > As a bonus we avoid unused clutter if it doesn't happen. I also get the > feeling that there isn't yet strong consensus on the anticipated use case or > the exact form it needs to take - we should let that process work itself out > separately before registration. > > I've chatted with Paul, and our recommendation is to remove the > original_transport parameter from DoH and encourage dnsop to update the > registration if/when a different standard needs to make use of it. > > thoughts? > > -Patrick > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
