Re: [Doh] [Ext] DNS over HTTP/3?

bert hubert <> Mon, 19 November 2018 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EE49130E11 for <>; Mon, 19 Nov 2018 07:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q3m8f6ua806p for <>; Mon, 19 Nov 2018 07:12:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B371130DE1 for <>; Mon, 19 Nov 2018 07:12:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id DCE1F9FD6E; Mon, 19 Nov 2018 15:12:09 +0000 (UTC)
Received: by (Postfix, from userid 1000) id 4878AACA4B3; Mon, 19 Nov 2018 16:12:09 +0100 (CET)
Date: Mon, 19 Nov 2018 16:12:09 +0100
From: bert hubert <>
To: Paul Hoffman <>
Cc: "" <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [Doh] [Ext] DNS over HTTP/3?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Nov 2018 15:12:22 -0000

On Mon, Nov 19, 2018 at 02:12:18PM +0000, Paul Hoffman wrote:
> > I've observed that the thousands of users of (I also do not
> > know how this happened) take around 22 packets per DNS query/response. 
> It would be valuable to know if this is this because your DoH server kills
> the entire connection after every DNS query, or because the clients are
> doing so.

It does around 2 DNS queries per HTTPS connection on average dnsdist-doh
keeps open an HTTP/2 connection for 10 seconds if it becomes idle.

> > Larger scale adoption of TLSv1.3 might improve this somewhat, but it is a
> > big number.
> DoH was designed for long-lived connections, so the number would normally be smaller after the initial connection.

I can only report what I measure based on several thousands of users.

> > I've also personally observed that a "slightly suboptimal" network
> > absolutely kills browsing performance in Firefox Nightly using DoH.  A naive
> > calculation shows that 0.5% packet loss turns into a 5% failure rate per DoH
> > query, which then can cause Head of Line blocking for further queries, which
> > cascades into "blank pages" getting rendered. 
> When you say "naive calculation", do you mean this is observed in the
> clients hitting your DoH server?  That would indeed be scary.  However,
> the Mozilla numbers tell a very different story.  It would be good to know
> which one is true.

My personal observation is that on a slightly bad network, turning off DoH
speeds up things massively and makes the web useable again.  This naively
makes sense, DoH uses way more packets and suffers from Head of Line
blocking, unlike plain DNS.

We have asked Mozilla to provide more details of their measurements, but
these have not been forthcoming.

Note that the graph published on the blog misses the 95% and 99% bins,
and does not include details on timeouts.

> > And, perhaps somewhat more provocatively, should we maybe not start pushing
> > DoH/2 if it leaves people with a sub-standard experience, causing them to
> > disable DoH?
> If the implementations on the client or server side make using DoH bad,
> those implementations should be fixed.  If they don't get fixed, we'll
> certainly hear about it.

There is already a Firefox ticket I think, but with Patrick and Daniel gone
or gone soon, I am not sure who owns it now

> > DoH/3 might be somewhat of a wait but it might prevent that
> > sour taste from developing.
> Without sufficient data, it's hard to say if there really is a sour taste.

Perhaps Mozilla can clarify further what they measured beyond the 7
milliseconds slowdown.

I may do some induced packetloss experiments to see if the "experience" can
be reproduced.