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

Phillip Hallam-Baker <> Thu, 21 September 2017 02:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 512AC132C2A; Wed, 20 Sep 2017 19:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Status: No, score=-1.698 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, URIBL_BLOCKED=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 fcvGI2H7Cj4I; Wed, 20 Sep 2017 19:56:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E02C132193; Wed, 20 Sep 2017 19:56:45 -0700 (PDT)
Received: by with SMTP id 93so3867822iol.4; Wed, 20 Sep 2017 19:56:45 -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=WM9PZxqF+tEX83LxWcTtLXdDUDMUstwgjO3sPHPTzK0=; b=sbd7hPzFBgtuJCIX6bDOpIxygWuqmiw2wdoJFwJtbebG1dMi1BWIB053Jv/FhcvP3F IsZEd26uc8fEpZiliXC4kKHodnr9+RA8Dxver8zFG4zGCfjImQybXIERVev15wQqputU YhEiOZAZYMkQluwYE4xwOIV0mIYYABLKPGydUzaD8POjJwq4nTFG2x9W43VpjzGV4pMz JoVxEk7UR4N29D3sD++KxH/j6k8i5TrTB3j9yzATS7AyiEM1f1+2Lwd5ssKsM8Ry8wQS 1pLaT3mjFOxoz778/pzIxShYqmDItnRZ9pOTmyOG2S/lwR8ThbswnpBFApXjkB3kKqah zudA==
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=WM9PZxqF+tEX83LxWcTtLXdDUDMUstwgjO3sPHPTzK0=; b=rFGGicnFobhv9sTu6WVsn+Q2hTcYxpXBBR7r9n0M6YuV/BDIVFwMCKZc5seYxZGh6W MwAqX9Fe/tRU23sbvt5kt5XKin4S/NzJQnWAmmGKbrAyu9iQ0QEzvMuFZX4d43ojRXT3 dZbrMEptXlA4Ac9nxsAYYF3fpaDNJ6FZYTvpYVHsQUQuzH3dU4aFTSSyQa44Vdpi7EEP CkF+9NEna3yuYeYtLRdfQDWf2PWyJQwghG4Ho6P72GpIbD/Ff0pKcHVEULXnBIYYGvqk gKl8mM8wKYctfx/FZXxsxOK+uOVaOt3q4SmsSootMHfW5Jbwze6OywuCk77s+bXKfssD 8yuw==
X-Gm-Message-State: AHPjjUiaPXmzXcz27aC4oAtNtHzS6g7DgK3DSeTp3wiBbnndpf4AzZQB nZegcwiBhaBeA0BbyuI3FyYJnAB2EZ0FoENZY7AUJw==
X-Google-Smtp-Source: AOwi7QD/auY7pxO5diW7HLeMKCrj8vwJB8hCwpcTnzmRcQLHrXN3QDzSsjV9Narjz1Vv8NzVGtozNhpgZI6fKNxsMpA=
X-Received: by with SMTP id r21mr867014oie.39.1505962604448; Wed, 20 Sep 2017 19:56:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 20 Sep 2017 19:56:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Wed, 20 Sep 2017 22:56:43 -0400
X-Google-Sender-Auth: GVdarUT3-oVApmT_Ur1saKjkNhQ
Message-ID: <>
To: Toerless Eckert <>
Cc: Adam Roach <>,, IETF Discussion Mailing List <>, IETF-Announce <>
Content-Type: multipart/alternative; boundary="001a113cf33c156fca0559aa3e97"
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: Thu, 21 Sep 2017 02:56:47 -0000

Replying to many threads.

1) I am glad to hear that it is agreed that any WG in this area will 'be a
marathon'. This is an important problem and it needs to be done right. And
that means discussing the set of use cases to be addressed, developing
requirements and only then looking at solutions. Do it right or not at all.

2) WS-* did too achieve its principal goal of making work for consultants.
It looked promising at first and then...

3) We might well want to delay a decision on this issue until after the IAB
ename workshop which might well lead to a game changer.

4) I agree with Mark Nottingham that this is an API thing and that IETF
does not own the specs where the key APIs are defined. That is WebAPIs for
JS (W3C) and POSIX.

But here is the thing, if IETF says a DNS interface should look like X then
by golly, I bet W3C and POSIX etc. will be only too happy to follow the
lead. And the strange thing is that IETF has already got a DNS Interface
which is really, really good and not the ones I proposed:

It has Apple's name on the spec so there is one major platform on board.
And it is 2013 and supported by quite a bit of running code. The only real
problem with the spec is that it is presented as 'one option' on how to do
service discovery.

Please, do not give me six ways to do a thing, give me one. And do not let
application developers choose either. Pick one method that serves all the
requirements and tell people to stick to it unless there is reason not to.
Standards are all about taking away choices that don't matter. Have six
ways to implement service discovery and I have to implement whichever one
is picked for a protocol myself. Pick just one as the default and it will
be there for me in a library.

Yes, we can grandfather legacy protocols like HTTP and SMTP. But lets not
force everyone to implement everything.

The only problem I have with RFC6763 is that the power of the idea had to
be hidden to get through process. This draft takes the ideas in RFC6763 and
takes them to their logical conclusion:

In short, what I think the Javascript, C, C# API for service discovery
should look like is:

Connection = Interface.GetService (<address>, <protocol>)

for example:

Connection = Interface.GetService ("", "_http._tcp")

That is it. I want all the extraneous stuff to go away or be hidden as
options. It should be possible for the DNS records to force use of a
security enhancement (e.g. a specific version of TLS with specific trust

That API could be implemented using existing DNS protocol at the client
certainly. The incentive to change the client-resolver protocol would be
motivated by latency, not by functionality. The big problem with DNS is
that the protocol is only reliable for one request and one response and
even if you could do multiple requests in one packet, the discovery
mechanisms are more complex and inherently require multiple round trips.