Re: [dnsoverhttp] Fwd: New Version Notification for draft-hoffman-dns-over-https-00.txt

Patrick McManus <> Thu, 04 May 2017 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12437126B6D for <>; Thu, 4 May 2017 08:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.965
X-Spam-Level: *
X-Spam-Status: No, score=1.965 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Y8qWGofFgt8 for <>; Thu, 4 May 2017 08:17:45 -0700 (PDT)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by (Postfix) with ESMTP id E6DDB129572 for <>; Thu, 4 May 2017 08:17:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id B44543A019 for <>; Thu, 4 May 2017 11:17:43 -0400 (EDT)
Received: by with SMTP id n4so12728454qte.2 for <>; Thu, 04 May 2017 08:17:43 -0700 (PDT)
X-Gm-Message-State: AN3rC/6/7vA3jinVHx+FE2k99rM9Jt0eHg5ufaEdwKusKO44LR1YtulM KxXTku2BSvK+Fi3P7EDRSbJnGyKx9A==
X-Received: by with SMTP id 18mr40652723qto.123.1493911063479; Thu, 04 May 2017 08:17:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 4 May 2017 08:17:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Patrick McManus <>
Date: Thu, 4 May 2017 11:17:42 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Martin Thomson <>
Cc: Patrick McManus <>,
Content-Type: multipart/alternative; boundary=001a11404b8643d23a054eb446e1
Archived-At: <>
Subject: Re: [dnsoverhttp] Fwd: New Version Notification for draft-hoffman-dns-over-https-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of DNS over HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 May 2017 15:17:47 -0000

Thanks Martin.

On Wed, May 3, 2017 at 11:52 PM, Martin Thomson <>

> On 4 May 2017 at 13:15, Patrick McManus <> wrote:
> > A new version of I-D, draft-hoffman-dns-over-https-00.txt
> A few nits only; I need to think more about how this fits into the
> ecosystem.  I am warming to the notion that you have flexibility in
> representation format, that's a key advantage of using HTTP.  You have
> neatly punted on the hard parts of that by choosing the dumb option to
> document, which means that you can bootstrap effectively.

ack - and I believe Paul has a JSON media-type document going on a separate
path that should dovetail nicely,  but not be a blocker. I certainly would
hope to see some JSON in the wild.

> The query string uses one of the worst encodings known to man.  Did
> you do any analysis here?  Is base64url bad for some reason.  For
> instance, I would believe that it increases the length of the string
> in the aggregate if you told me.

will open an issue for more analysis.. did one example by hand and it was a
~wash size wise.. and the hex made a clearer example :) more study would be
good, but its a micro opt given the existing bounds on the sizes involved.

> You should use a parameter name for the query string so that you at
> least have the chance to automatically discover a service and make
> requests in other forms using the query string without sniffing or
> other such horrors (conneg works fine for the POST variant, but you
> are pushing those uses to a method that isn't a great fit).  What you
> have consumes the entire usable space in the query string, so it would
> be hard to get in edgewise with an alternative query form.

so this is interesting. I started down that road, but couldn't really
figure out how to do any form of negotiation beyond the MTI with it so just
stuck with the simpler variant you see in -00. 415 seems to apply
specifically to content-type and bodies so wouldn't work as a signal. Or am
I being too pessimistic?

Strictly speaking we don't need the uglier GET variant at all - the POST is
absolutely cacheable. But realistically speaking that will not work with a
lot of existing caches.

> Do you really need to encode the ID?  I realize that might be
> construed as opening the floodgates, but it is going to make caching
> that much more fragmented.  Can you not just trim it off?
low friction of using an existing (albeit encoded) format traded off vs a
couple bytes... that is why the normalization of ID SHOULD is in there tho.