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

Davey Song <> Wed, 04 April 2018 04:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E18E4124234; Tue, 3 Apr 2018 21:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4YgOGo3wNfoe; Tue, 3 Apr 2018 21:45:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37784126D0C; Tue, 3 Apr 2018 21:45:31 -0700 (PDT)
Received: by with SMTP id q38so12436379uad.5; Tue, 03 Apr 2018 21:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UXNFvgIIpy1Q72KQ1o06ZUPZBMBMydSKp5RgdTWugy8=; b=FKUaUw5YwerOlyeeBw/O1kDJdvzEgzC7v4URKqRTWcPjpoXP4qzu4P+MjbC5Lfm42I 7gn3pLFoxYcj04M//IK/v6DzSM6iA6STe3geqz6YTBHz9lv+PuAYk1U9bHtAWvlWTlfm MusdSJNyezvmIV8vd2CwX5hQuDcFSEDKiWdmg35OtSMzYJYXlL8cFbFOuP17Cb4liANe ZRGJftgVPs6bKkq09TyubgXqJaLM10Z4yoNNLY2bKvBgPoPnODMyM8Z7KXsGh1yZHTqF mU+pEKkJKToByzamkL9AltORc/ORsAw+XmvrnEB8ge5BppXPwFc7deLFhoOwUFCVxZoZ +9kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UXNFvgIIpy1Q72KQ1o06ZUPZBMBMydSKp5RgdTWugy8=; b=HfFQLoX87gEtyqMh3FPRnRupDRUK3/KnP9GVe7k/kDwq2ZrLvzPdtWy1VT6PYMTeU3 dGft+aoDv/nrfgZs9sC+9KOzY/HeLHdKSW5XySYUXV/EDbBoUU6OfWkhz/dDXTB5bYfz /79UtHK5Hk0YOaNw9bD5BclWlztbXXaDEp9TWaLPhNXc3Xw7pE+wEslxYdl5DVZaCaZb dIeH4jlZ49EndeRWOikZPginp+9fNDtxgsLsneLXbLOExmGfw80PexkrR7A3zuV8y9FI kBj7GN7xhSSSzER+7Y/C6JOILGqeCOTxQYa/niKGkw5LQGArgCpLqyS5gh+Q+9Br/gNB BMJA==
X-Gm-Message-State: ALQs6tBhN1iU2kYwnYatbDY5ddJCjCgvGqI1NUDe/4cX6x349ovXa7Ko PLPVmfZ4gjh6subKMmfbAE9FtkR2WTPP9oKy53Q=
X-Google-Smtp-Source: AIpwx4/tJJkXTVKvpyprEEg1rUZhBpGzNzcBgZkwYDqf/QLYlOBjsGhdhsMbOce2cUrNWTxYercJLkDhQWWshG6t9LM=
X-Received: by with SMTP id w7mr10150695uaa.145.1522817130147; Tue, 03 Apr 2018 21:45:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 3 Apr 2018 21:45:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Davey Song <>
Date: Wed, 04 Apr 2018 12:45:29 +0800
Message-ID: <>
To: Martin Thomson <>
Cc: Paul Hoffman <>, dnsop <>, DoH WG <>
Content-Type: multipart/alternative; boundary="f403045e343419b4230568fe7e26"
Archived-At: <>
Subject: Re: [DNSOP] [Doh] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Apr 2018 04:45:34 -0000

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.


On 4 April 2018 at 10:35, Martin Thomson <> wrote:

> On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman <>
> 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