Re: [Doh] Associating a DoH server with a resolver

Kenji Baheux <> Mon, 29 October 2018 09:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67278130E0A for <>; Mon, 29 Oct 2018 02:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, 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 boSe28T-zzc4 for <>; Mon, 29 Oct 2018 02:30:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64CDA130E09 for <>; Mon, 29 Oct 2018 02:30:12 -0700 (PDT)
Received: by with SMTP id x3-v6so7046351lji.13 for <>; Mon, 29 Oct 2018 02:30:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kHpz5t3SCGUARFg5xl9IS7jKvyi3LLjgdwUwKctCqk4=; b=o9utD9K5V62o9W+Dec+rtmX7bu3uTUAqnjx8nHJDXh1RQlWS5qFHrxqvJRgadA4gjD CDM48AbREis31Qeineor+sqz/A4girnno8hCYxCr7UbhMyAfiL6vMOCq1e6GLbuuaZ+S 0R/uWPhxrmjLxgWUY5Ac8BUFDkTkZF8fug+3SbBCOlfX4vi18z7C00AVeJAHI/sljpmm DAQbavEeGfKAXyQrcG84LTX79jNy0CjZGUlgP/C2EBdNNw47ojuID/G/9zZX8eHUqG1K 01dPKKjowSM8/39lwc2tPR4libsaGe95emN451W1HoaFpkKrPmhbjjR+um/GvlBW7KeM Jwjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kHpz5t3SCGUARFg5xl9IS7jKvyi3LLjgdwUwKctCqk4=; b=Ao8Iyg85DCqh4sQREvYmT35YxE0yrOXptC/odfar3UGDoKvKa9jcriMhhEZiPvFxdD nWKJwdcN2m+vnaIDXt06GX+jTpvnnqwSbATsBdX2T4TIlXr51m+fZ1RuO2rrYit+3tYp o7f9yMxI8MdEwuUt7ZiRW/oliyrIiQCSNONqLayU/520Piommv4nHWkeqRmh9X/RKTW7 gdPTBtJrjaxjBW+AirHOLMv3jz6NDgGv86SAwstOGbOR7umZ/cs5GOdxkJWc/Gw5ILL+ xZsNI+p2DnaetsDi2LHaMnMg+YLdHQV6qeMWYFlNYsrOwpy8jHo5lKkHso5sSx6iWIc2 W8Ag==
X-Gm-Message-State: AGRZ1gJNFOy1H07WH6YMduHVCsjFHdDKgVUveoYNsFI/W/ZeawI3mI/n qSQg7A27K871QQL+aYFfEWpugDEkVyr1lgTc0ykAG6H58Zs=
X-Google-Smtp-Source: AJdET5cRr4JzgS/MjFmQs30MWqpaxLYbgz/rj8eJGGxP38Gl+osO0h9nj/7cPlSCdC2APf2GVusICSwtefhnCBJ8KnI=
X-Received: by 2002:a2e:96c6:: with SMTP id d6-v6mr9391443ljj.35.1540805410081; Mon, 29 Oct 2018 02:30:10 -0700 (PDT)
MIME-Version: 1.0
From: Kenji Baheux <>
Date: Mon, 29 Oct 2018 18:29:57 +0900
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000023162e05795ab769"
Archived-At: <>
Subject: Re: [Doh] Associating a DoH server with a resolver
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, 29 Oct 2018 09:30:15 -0000

*Apologies for starting a new thread (maybe), I couldn't find a
straightforward way of replying to a thread that pre-existed my

*tl;dr:* I'm involved with Chrome's DNS over HTTPS effort. While I haven't
yet read the proposal and I could be missing some important context, I
support the use case (i.e. facilitating the discovery of DoH support from
an existing resolver).

Paul Hoffman said:
"I would want to hear that [*no browser vendor is interested in ways to
find the DoH version of a resolver* (paraphrasing)] directly from the
browser vendors before abandoning this work, particularly because we are
hearing a lot of interest from organizations who want it."

I'm involved with Chrome's DNS over HTTPS effort. We are considering a
behavior where Chrome would identify if the user's existing DNS server
supports DoH, and if so, then perform an automatic upgrade (TBD: silent or
with an opt in/out prompt).

Our short term approach is to have a list of known resolvers that support
DoH and do the mapping internally. But, in the long run, this doesn't seems
ideal. Also, for custom resolvers, it seems preferable to have an easy
configuration path instead of the potentially cumbersome URL scheme +
POST/GET choice?

So, while I haven't read the proposal, and it's possible that I'm missing
important context, I support the use case.

Product Manager - Chrome
Google Japan