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

[Davey Song <[e-mail]>]

I'm sorry to hear that. I would like to provide some information as a
background if it's useful.

dns-wireformat-http draft was originally proposed in DNSOP WG as a
experimental draft in early 2016. We focus on the requirement of enhancing
DNS availability bypassing the middlebox on the path via HTTP tunnel.  It
was later adopted in DNSOP WG as WG document. I think it was an original
and sound work deserving us to work on at that time.

However, it was postponed in 2017 and we are told that HTTP people has
concern on it.  At that time, draft-hoffman-dispatch-dns-over-https was
proposed as a standards track aiming to defined HTTPS as substrate
transport for DNS which is different from the DNS over HTTP tunnel case.

Later DOH was created forcusing on HTTPS as DNS transport protocol. We were
told that the proxy and tunnel case is not in the scope of DOH but we are
suggested use the technology developed in DOH. At that time I still think
it is valuable to introduce a use case of DNS over HTTP tunnel and define
necessary protocol. The compromise is that we drop the free use of
HTTP(without TLS) and HTTP 1.x because DOH has mandatory requirement on
HTTPS and HTT /2.

When I submited dnsop-dns-wireformat-http-02 weeks ago, I asked if we could
introduce a optional parameter which is bettern than a new media type
"application/dns-tcpwireformat". I suppose that optional parameter should
defined in dnsop-dns-wireformat-http-02 instead of DOH draft. However,
after original_transport optional parameter was defined in 05 version of
doh draft, I'm afraid it was enlarged its scope to contain the proxy/tunnel
case which make people think dns-wireformat-http is useless. I'm confused.

So I would like to ask folks in the two WGs how to proceed:

1) Should dns-wireformat-http draft insists on the original defination of
DNS over HTTP(s) tunnel with new HTTP header as a experimental document?
Because that is the original experiment we have done to show the capacity
of DNS over HTTP(s).
2) If the answer is no, how should  dns-wireformat-http draft align itself
with DOH document. My suggestion is to define the original_transport
optional parameter in  dns-wireformat-http draft.

Or Is there any other way out not abandoning our work? As the co-author I
still want to rescue it.

-Davey



On 4 April 2018 at 10:35, Martin Thomson <[e-mail]> wrote:

> On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman <[e-mail]>
> wrote:
> > Martin: Are you saying that you want DOH to remove the optional
> parameter from the application/dns-udpwireformat registration? If so, what
> do you propose for the DNSOP WG?
>
> Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
> concede that I'm probably missing something.
>
> By my current understanding, draft-ietf-dnsop-dns-wireformat-http is
> indistinguishable from a specific implementation of
> draft-ietf-doh-dns-over-https.  That is, if a DOH server wanted to
> service all its queries by forwarding requests to a resolver [1], I
> can't see how that would be disallowed by DOH, and that's exactly what
> draft-ietf-dnsop-dns-wireformat-http appears to describe.
>
> Convince me that this isn't the case (or not, and I'll be in the rough on
> this).
>
> --Martin
>
> [1] ...after randomizing the ID.
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>