Re: [Doh] [Ext] DNS Camel thoughts: TC and message size

bert hubert <bert.hubert@powerdns.com> Thu, 07 June 2018 21:58 UTC

Return-Path: <bert@hubertnet.nl>
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 156D2130FAC for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 14:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level:
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 n6LqQaCNscQ3 for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 14:58:56 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939BE130DDB for <doh@ietf.org>; Thu, 7 Jun 2018 14:58:56 -0700 (PDT)
Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id CE4D29FB55; Thu, 7 Jun 2018 21:58:51 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 433FBAC5B1B; Thu, 7 Jun 2018 23:58:51 +0200 (CEST)
Date: Thu, 7 Jun 2018 23:58:51 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Dave Lawrence <tale@dd.org>, DoH WG <doh@ietf.org>
Message-ID: <20180607215851.GA32738@server.ds9a.nl>
References: <20180606093212.GA23880@server.ds9a.nl> <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org> <CAOdDvNq9g3ghbg9fkfhP+ZA4-6E5oDNFCGo6NN9bydqUX76cLA@mail.gmail.com> <20180607093647.GB32326@server.ds9a.nl> <CAOdDvNriZDjU9yqUQjqN4fO84ENPWO3si-QePiKRgt+7VJVK0g@mail.gmail.com> <23321.27027.73356.94056@gro.dd.org> <CAOdDvNr=kLHPCtCHRx4=rpA1oDogQqdAJ0nR156BWABiFP_bzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOdDvNr=kLHPCtCHRx4=rpA1oDogQqdAJ0nR156BWABiFP_bzA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/QltumTQMzVWNeJvXWhKp2B6pWLE>
Subject: Re: [Doh] [Ext] 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: Thu, 07 Jun 2018 21:58:58 -0000

On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote:
> > "Sort of".  Wire format itself does not have the limitation.  Its use
> > on certain transports does.  This distinction needs to keep being
> > made.
> tale has convinced me of this point.

In the interest of reaching consensus, can we park this discussion until
another message type is invented and standardised that is not a DNS message
in "wire format"?

Whenever we make life harder on the whole DNS implementation community, we
had better have a very good reason for that. 

To put it bluntly, a significant part of the DNS implementation community
(ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit is
here to stay for now, so I don't see a viable consensus for expanding DNS -
especially given the lack of concrete usecases.

Finally, I note that the DOH charter contains the following:

"The working group will coordinate with the DNSOP and INTAREA working groups
for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
respectvely.

In particular, DNSOP will be consulted for guidance on the operational
impacts that result from traditional host behaviors (i.e., stub-resolver to
recursive-resolver interaction) being replaced with the specified mechanism.

Specification of how DNS-formatted data may be used for use cases beyond
normal DNS queries is out of scope for the working group."

It may be good to point out that 'normal DNS queries' have never involved
getting >64KB responses. We might also have to consult DNSOP about changing
DNS semantics, an activity they aren't stimulated to explore. 

Finally, I do really understand how much fun it would be to liberate DNS
from its pedestrian 64KB shackles. It is an arbitrary limitation, and
perhaps one day we'd love to put gigantic post-quantum cryptographical keys
in DNS. But given the amount of developer cycles in DNS, please also
understand my (our) reticence in overhauling this ancient protocol. 

	Bert