Re: [Doh] Clarification for a newbie DoH implementor

Ben Schwartz <> Sun, 19 May 2019 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24E161201D4 for <>; Sun, 19 May 2019 09:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 baBo3t_F4jBT for <>; Sun, 19 May 2019 09:09:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BADC1201FA for <>; Sun, 19 May 2019 08:41:43 -0700 (PDT)
Received: by with SMTP id m1so7512085vsr.6 for <>; Sun, 19 May 2019 08:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0lHyH4zPN5BJ2NBy2BWiylLsSOZ050gr2xexcj+tU5k=; b=pmKT01JD5Ko0hBCwWlCkEu+ohSegbr3MyJXv/via4eeFSfoyvbstJDKse5R+9poiFu Xwk/L3l4oavu3SWILu3vT3h52DUyR27z4OkldjUeiEwxY1qyNy/GUq3K9NKhc5k3fV7/ RyblghoCfLrbRGLKTTtZyHwjqCEimp50PbIcYEWiaDid508Vi50FM0ssQV3kriKueiNc DmFVgz7RQerdg0VZdbCXiDCk9orpADU7rVIWzcdiAnSDEMDlidnYYPkCNoPQapTnSecQ d/dMyc7jA9ahAuUkhxUehqmhgVej6zGW8ooo53gT8g9jI6uDJsnCs0PpO25ZATMzPl3k dLVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0lHyH4zPN5BJ2NBy2BWiylLsSOZ050gr2xexcj+tU5k=; b=UvqRCMQMff5Fhve9+rMLVIaSTMxTApIJZC+T5H8OpMPvNI3MrEn2eMzUwDiGJFakpH tj2WgLU5J/pAMvE9RayFHmC4Ezd177FC3HDIEUgLlpIVj5lPK4dB/YhZghiC3vGe5Tkz E8rPG3BtEdw+jCd7/D/4llCWddDpFJxxRWEscFY1g12EVI3zvejAUo0vjwMDHtDUjm6B 1NREQ4EdrpL0eZ+6cckeVnQzQFYTUZDu8pJA8UsHt2Z9eW8k3dAmKYUjwynkxo8ydvN5 CL+05mpQXUbszRN7nv2bIktoLX44HoshLoVT7pM9P9Hib2VoTrzE5cPAMtkxBviFvKr8 yhPw==
X-Gm-Message-State: APjAAAV5sFTRdP3nXgfbEGr5+G9slpH6sD3M9OFTS/VhRZoTVcN+drQG tNA9SyMnwjWmYdq4X184FzANZisCmxpF3XxodoCjyG+HwIstyA==
X-Google-Smtp-Source: APXvYqxHh92y7R9UjlFs7ref8SSwVm3Es6i9VO/X/kTot1mitKW1QTI6Co3da0WVLZTzez1MHUQqHq19SxGweIYrpAU=
X-Received: by 2002:a67:1e47:: with SMTP id e68mr33408847vse.1.1558280502238; Sun, 19 May 2019 08:41:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Sun, 19 May 2019 11:41:28 -0400
Message-ID: <>
To: Mark Delany <>
Cc: DoH WG <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d4cbdf05893f73f8"
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 16:09:24 -0000

*From: *Mark Delany <>
*Date: *Sun, May 19, 2019 at 1:53 AM
*To: *DoH WG

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.

Given the large number of potential deployment scenarios (including the two
you've noted), the authors felt that it was best to focus on specification,
and avoid attempting to enumerate the expected patterns of usage in each

> 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.

The classic DNS protocol doesn't have any such role indications either.
Thus, when I send a query to my network's advertised DNS server, I have no
idea whether it is acting as a recursive, forwarding my query to a
recursive (e.g. dnsmasq), or something in-between.  This is transparent and
generally does not cause problems.

DoH is a transport for DNS.  Since DNS has no protocol-level indication of
these responsibilities, neither does DoH.

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.

In practice, none of this seems to be a problem.  DoH servers simply do
their best to fully answer the query, securely and in a timely fashion.
The details of that are left to the implementor, as it is with classic DNS
servers, whose detailed behavior varies widely according to the preferences
of the operator.

> Mark.
> _______________________________________________
> Doh mailing list