Re: [Doh] Clarification for a newbie DoH implementor

"Mark Delany" <> Sun, 19 May 2019 05:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D06D1200E9 for <>; Sat, 18 May 2019 22:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W6dmst5bldax for <>; Sat, 18 May 2019 22:53:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CC87A1200B2 for <>; Sat, 18 May 2019 22:53:03 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 041F83AFF7; Sun, 19 May 2019 15:52:56 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple;; s=2019; t=1558245176; bh=UyoGbNs8FbHbgKHLZdUdZbV24hg=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=ar2/+/cPX7yx5NANosRfcl9eR4gOGsIW7clLg1lBJWk4ZSQFhKUTDIObiPqxNj46j wDx6tt8dzXc90kT4PYd47H8tl+2uAGPWE8TVieCRnF3wulkAeePSfx2D2UDE0hdQ5L cS/Vf9DbVnykwnH2rU6k7qg0+kiJ41DmUZ1o0k94=o0k94=
Comments: QMDA 0.3a
Received: (qmail 45718 invoked by uid 1001); 19 May 2019 05:52:55 -0000
Date: 19 May 2019 05:52:55 +0000
Message-ID: <>
From: "Mark Delany" <>
To: "DoH WG" <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Doh] Clarification for a newbie DoH implementor
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: Sun, 19 May 2019 05:53:06 -0000

On 18May19, Ben Schwartz allegedly wrote:

> I don't think the implication you describe is intended.  This sort of
> reissuance is the expected implementation in the architecture you're
> describing.

Thanks. I think you're right that I've been thinking of a DoH server
as being a dumber component than perhaps intended.

But having to glean this model from potentially unintended
consequences - such as a forced outcome for sensibly dealing with TC -
is a bit disconcerting.

If you infer from RFC8484 that a DoH Client is a simple call to an
HTTPS library embedded in an application you get quite a different
architectural perspective than if you infer a DoH client as being a
service on your home/office gateway or portable wifi AP.

In the former there is only one resolver library in the path, in the
latter there are two (per your "easiest implementation" comment). How
you divvy up roles and responsibilities in each of these models
substantially differs.

In the former model most, if not all, of the stub resolver smarts live
in the DoH server. That could include nameserver timeouts, TC retries,
ECS settings and more. That agrees with the inference you suggest.

In the latter model the division of labor is much more ambiguous as in
effect you have one stub resolver calling another with both having
local configurations and both assuming they have sole responsibility
for client-side errors, retries and feature management.

Put another way, in the former model a DoH server most closely
performs the role of a stub resolver in the latter model a DoH server
most closely performs the role of a recursive resolver but it has no
clue as to which one it is being used as.

It's a pity the second model didn't get much attention because if DoH
becomes pervasive, it's hard to believe it will be as a dumb HTTPS
client embedded in a bazillion applications.

Not much to be done about all of that now I supposed. The main
conclusion I've drawn thus far is that the first model is relatively
straightforward, but the second model could benefit from both
specification guidance as well as possible protocol support to
negotiate overlapping roles and responsibilities.