Re: [Doh] WG Review: DNS Over HTTPS (doh)

Phillip Hallam-Baker <> Fri, 22 September 2017 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B170B134513; Fri, 22 Sep 2017 09:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BEEyl73dOPOm; Fri, 22 Sep 2017 09:00:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CE42134516; Fri, 22 Sep 2017 09:00:46 -0700 (PDT)
Received: by with SMTP id v36so4098348ioi.1; Fri, 22 Sep 2017 09:00:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GjR0WOAbC9ExvNeujs21iMPGZ5kZV4i3bVXLjxf9+kk=; b=TXftlTYyDwNS/21X8s4Ij8fz2ngACxkNuLeXDhWc4akbLg4BQDkrorBJFZu1BL9oGd MDsq9JBeelf0GjmTQ9c8ghFTQpQf7XsTlOkeE90JsG8xYfDrbiQWzAnFcl3qMmnqEpLC j07iH144FTEoKXNM7CtCJUZzO2N4zZ5ZTmND5lW/H+qnzHV9O9yVufbWiAXM06WpfS3a /C+bw/wLHzra/+A9tkpmxSzKNZ/tkJZK2mJcclZ77Rhagxxh0ccW/0MWoendmQA3Ehbo ZSeBrPDixFPX766nULpG0TGNx/6+LWyIKO6JxMzUh4IOGD8Y0X0yHY3ZGWEQo0aAEjuv A7cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GjR0WOAbC9ExvNeujs21iMPGZ5kZV4i3bVXLjxf9+kk=; b=lDT2vfaFQSPgt5bA692tjOnImpEKwOw7BhtagOYY03fmEpEWYcIDHfDhAJsGQEw9Cg ukyX2Tfnqhf8czhW/sif37yGMuHDUq1osteW2Xp09zYKActuUWNHKy90quLX/mSEv6ON /3o4Txf4JqFJsFn1smgUpL3lOoUimV735Wc4WM4R8Bhg2hZ58J0N2QH51vXAyCeFuM7o ZYh9j+3vi6PbN4cfPzphATEfBRfZNXSDu5CQdrSzlRP0S/wQ5lgj4OhCDZr0MtGLtIrP yht6R7TqnUPYN+yBhrIQU8M008vwJeK+tcMHY4Xx1hNpTZyrOaGHsRiTji6jlMq6oQyb 4EXA==
X-Gm-Message-State: AHPjjUhmz3CCp+Pt6XfqbBRmMsyPUrnmRKSjBesfbPV3tt4TIoeH80dN vCbvD7fqAyFseL/y1x5o8V5eURJvUka9QD7xCkQ=
X-Google-Smtp-Source: AOwi7QBjTJSeT0fkDLl+S0vdWYIo3El8TadxjQR42JsQJN8wLfEDxYvz71mLMhdrTTJCxCz6Tcr8f211sCTASedn/hQ=
X-Received: by with SMTP id r21mr7289615oie.39.1506096045017; Fri, 22 Sep 2017 09:00:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 22 Sep 2017 09:00:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Fri, 22 Sep 2017 12:00:43 -0400
X-Google-Sender-Auth: 5E6NBLfJgOLDITSPn8V-f7VqGnE
Message-ID: <>
To: Mark Nottingham <>
Cc: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= <>,, IETF <>
Content-Type: multipart/alternative; boundary="001a113cf33cc2ed510559c94fd8"
Archived-At: <>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Sep 2017 16:00:59 -0000

On Thu, Sep 21, 2017 at 9:07 PM, Mark Nottingham <> wrote:

> I suppose, although it would be good to understand if perf problems to a
> dhcp configured resolver are widely encountered.
> I wouldn’t be against text in the charter that allows the wg to consider
> mirroring currently defined (by the ietf) dns discovery mechanisms. I’d be
> against definition of new ones.


​I think that everyone really needs to take a look at this spec: It is not the best description of a
general DNS discovery mechanism because it was not allowed to be presented
as such. It had to be couched as an 'option'.

The DNS folk think that the answer to every problem is a new RR and they
are oblivious to the fact that the DNS protocol does not allow that. Even
if you can populate the records into the DNS your provider uses, the fact
that you can only query for one record at a time or for all records makes
use of multiple RRs for discovery unworkable.

What I would like to see is 'take RFC6763 as the starting point and define
a common set of tags for use in TXT'​