Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)

Petr Špaček <petr.spacek@nic.cz> Wed, 13 June 2018 17:47 UTC

Return-Path: <petr.spacek@nic.cz>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0A4130F6D for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 10:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.021
X-Spam-Level:
X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ecNKuvALbY6 for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 10:47:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD852130F6C for <doh@ietf.org>; Wed, 13 Jun 2018 10:47:42 -0700 (PDT)
Received: from [172.20.6.227] (unknown [172.20.6.227]) by mail.nic.cz (Postfix) with ESMTPSA id 986D6601B2 for <doh@ietf.org>; Wed, 13 Jun 2018 19:47:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1528912060; bh=xlWVUxSgWVAdaLnTEsZJtBNmFOLKkCJYuUkEtt2FCy0=; h=To:From:Date; b=bWrvTa6nT5kYr05/cAwrBcSgAPfGtqz5BtWKUpRR8mWLwZ9Xa8hwk74QBApPdNTaH MIotTBhyIZqSc1CI+FWtlAjQIys5hkcIkCOQK09rNA38KoAXIIF3qUEx5ZWZVH9yf0 IbxR1KO/O585CCWHcpnNUr3a4Gj1OIePlLRo70tk=
To: doh@ietf.org
References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz>
Date: Wed, 13 Jun 2018 19:47:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/D9YuxvsBJcgEIRv7K9wRgaY-LOM>
Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2018 17:47:46 -0000

On 13.6.2018 00:19, Paul Hoffman wrote:
> On Jun 12, 2018, at 2:46 PM, Ray Bellis <ray@bellis.me.uk>; wrote:
>> I do think it would be helpful to consider in more detail where DOH is
>> expected to sit in the DNS architecture.
> 
> This is the DNS: "is expected" almost always turns out to be wrong. (No smiley appended.)
> 
> The same can be said for HTTP.
> 
>> Is it going to be a new "first class" transport (sic) protocol, or is it
>> merely a tunneling protocol for carrying DNS messages whose sole purpose
>> is to provide interworking for those that cannot use the "normal"
>> transport protocols because either a) there's a stoopid middlebox in the
>> way, or b) they're a web client ?
> 
> These are good questions, but if we try to base our protocol on what "is expected" and our expectations turn out to be wrong, we will probably design the protocol badly.

I think Ray was too shy to ask The Question:

Is the goal of the current doh WG

a) "standardize encodings for DNS queries and responses
that are suitable for use in HTTPS. This will enable the domain name 
system to function over certain paths where existing DNS methods (UDP, 
TLS [RFC 7857], and DTLS [RFC 8094]) experience problems." in an 
interoperable way, i.e. doing a thing the WG was chartered to do?

OR

b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the 
original DNS protocol? We badly need DNS 2.0 so let's admit that, it is 
not a shame.


If the answer is b) then I will applaud and support doh doing DNS 2.0, 
we only need to stop pretending that current doh work is just a new 
transport for the original DNS.

My reading of the doh charter is that doh protocol is a transport which 
should help to get the existing DNS to endpoints. Changes beyond 
existing DNS semantics are work on DNS 2.0 and thus outside of current 
doh charter.

I strongly support work on DNS 2.0 but we must not pretend that it is 
still the original DNS with minor tweaks, and recharter doh to admit that.

Clean cut will make all discussions about "what happens if there is a 
dumb proxy" moot because it will be clear to everyone that "doh is going 
to be DNS 2.0".

Or even better, let's use a new name for the new protocol:
HTTP naming system (HNS)
and do not confuse everyone with references to the legacy DNS.



Can we get consensus call to answer what doh WG participants want to do?

a) just do new transport for the existing DNS
OR
b) invent "HTTP naming system" without the burden of legacy DNS
(HNS == DNS 2.0)

Can we get clear answers to this question? Pretty please!

-- 
Petr Špaček  @  CZ.NIC