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

Martin Thomson <> Wed, 24 October 2018 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11A0412D4EA for <>; Tue, 23 Oct 2018 18:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 yiV8TyEWgi8H for <>; Tue, 23 Oct 2018 18:08:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BECB128CE4 for <>; Tue, 23 Oct 2018 18:08:43 -0700 (PDT)
Received: by with SMTP id k64-v6so2703310oia.13 for <>; Tue, 23 Oct 2018 18:08: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:content-transfer-encoding; bh=52arPFwH3u+tUbPGkMH5NlcOsV/qzZgx9lBNLk//yS0=; b=CBFbfZ+QgV8rqQ6jDfYaQB23+2xlCvqAf1M/vZoBo9M/jXz3XT/Y8GaKMqtH5NhsId yM3Ytp2zAUkem0hB8sHlkdYjxbdrDzeGSARN2FgAc/pnmnAikIkB35LOFFW3/qtpxNI8 /kW9oMFqPyX6s5x7A/OgOKABxhdWyo4pQOAobWPjY9D5N8hQv3hNzdH9VgkANVX97LTE tSzbEytKkxUKGEVke5xvfng/YmoIskgAogkPDzV+3pq7Ohvy1JsW67TADrzKCnPNfwQF SEga+6sojzR6QuiJ/4M48BedJIPnuUXe8pSCVx66wnMh7qoA0Te6rE7KOyR8EwGiBHVU p3mw==
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:content-transfer-encoding; bh=52arPFwH3u+tUbPGkMH5NlcOsV/qzZgx9lBNLk//yS0=; b=Mv3WzPNbp2j/mQtK5CP1iQ6drxRVMjATlai0KqtO6jO8FEmcnelaZDkUhqoiO+EdiX caTBFV4Z0w9rewNrZskf+Hr5RkvqG3aBi3VEh/q69ibrGzLDOyOZmGT1jnIqZt43A2DK B76KRmFWYxZtopjrrKuBFCoahZjmOCdshl4MxHdg3INZgZ/bhUQ/SA2n37VH0gqQ/hq/ nED4drxIW5xK+F7mAYibIkP8I/M1zkqx+k/3Iq7k8sRafgCsXmL18iy5Er+fadl6NOuq BpyVPEnv7eK9xsjFQil+kf19lWKyP3S8Slfl0zkZMOIww9yi359r9jgz/0QrbA8dV+Ok mP9w==
X-Gm-Message-State: AGRZ1gIzJQYAAoYhAZCkflAWxiTD1OR0yKGoc1Pn3VHS2pqkJYozPgir sgnoyrxaHFDKUxwOGXXCd/q/UNa0DAt73e6cTME=
X-Google-Smtp-Source: AJdET5fDPVYb9acEsE4XInBLxMBNNQ9V04FLG8roXAJUfVvakPktwRS0wKiNZ/h8y0qguQkGkEhVyaDak+umUUq++8k=
X-Received: by 2002:aca:fd89:: with SMTP id b131-v6mr299677oii.30.1540343321011; Tue, 23 Oct 2018 18:08:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Wed, 24 Oct 2018 12:08:31 +1100
Message-ID: <>
To: Paul Hoffman <>
Cc: DoH WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 24 Oct 2018 01:08:45 -0000

Why do the IP-based spelunking?  It requires that the resolver (which
might not be a DoH server) do HTTP as well.  Can't you define a record
that could be placed at the name?  I hesitate
to say TXT, but I can't think of a good reason not to use that in this
case.  Multiple such records could identify different DNS-over-foo
On Wed, Oct 24, 2018 at 7:15 AM Paul Hoffman <> wrote:
> Post-RFC-publication greetings. One of the topics that has been active in the DNS community since the standardization of DoH is how a browser or web application could use the resolver that the operating system on which it is running as a DoH server, or at least to use a DoH server associated with that resolver. I have taken a few stabs at designing a protocol to make it possible to fulfill that need; the result is the draft below.
> The draft is still in a very early stage. In fact, I've changed the underlying mechanism three times already because I forgot what browsers and operating systems could not do. I *think* the current draft is possible, but would not be surprised if someone pointed out that even this attempt is wrong. Regardless, the desire for such functionality seems strong.
> Also note the Security Considerations section of the draft. In short: all this gives you is opportunistic encryption because (I believe) we can't get any better now. I would be happy to be wrong about that, of course.
> Thoughts?
> --Paul Hoffman
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>         Title           : Associating a DoH Server with a Resolver
>         Author          : Paul Hoffman
>         Filename        : draft-hoffman-resolver-associated-doh-04.txt
>         Pages           : 8
>         Date            : 2018-10-23
> Abstract:
>    Browsers and web applications may want to know if there are one or
>    more DoH servers associated with the DNS recursive resolver that the
>    operating system is already using.  This would allow them to get DNS
>    responses from a resolver that the user (or, more likely, the user's
>    network administrator) has already chosen.  This document describes a
>    protocol for a resolver to tell a client what its associated DoH
>    servers are.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> _______________________________________________
> Doh mailing list