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

bert hubert <bert.hubert@powerdns.com> Fri, 08 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 1F225130DC2 for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 14:58:47 -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 DKi0HVLWbcuO for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 14:58:45 -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 776CE130DC1 for <doh@ietf.org>; Fri, 8 Jun 2018 14:58:44 -0700 (PDT)
Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 5B9719FB55; Fri, 8 Jun 2018 21:58:41 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id CB321AC102C; Fri, 8 Jun 2018 23:58:41 +0200 (CEST)
Date: Fri, 8 Jun 2018 23:58:41 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: Dave Lawrence <tale@dd.org>
Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= <olafur@cloudflare.com>, Mark Nottingham <mnot@mnot.net>, DoH WG <doh@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
Message-ID: <20180608215841.GA20830@server.ds9a.nl>
References: <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> <20180607215851.GA32738@server.ds9a.nl> <CAOdDvNqNpZ8fKPCO5sEqjROBHjg4wx-GGPMYSSynode10jeC0Q@mail.gmail.com> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <CAN6NTqxA4PcrtS_3umwGERLt9WPoX4p0a0u8pL-O2=CKKTBfyA@mail.gmail.com> <23322.62892.251560.128565@gro.dd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <23322.62892.251560.128565@gro.dd.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/MhCj0X38DQYM1EwHo1d_jD491vI>
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: Fri, 08 Jun 2018 21:58:48 -0000

On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote:
> Ólafur Guðmundsson writes:
> > Actually I think what DNS people are concerned about is:
> >  Query over DNS ==> DoH ==> Auth server generates big answer ==> Doh
> >  Reply => Answer over DNS fails due to size limit.
> 
> I'm a DNS person and I don't have a concern about this.  The software

First, we should be clear no one has identified a usecase for "megabyte size
DNS messages" that can't be solved today already.  So the question is, for
no identified upside, what is the downside?

The downside is that if we do this, "large DNS messages" are a thing.  They
can happen over DOH transport.  Please realize nothing in the draft says
anything about this being restricted to resolvers.  Authoritative Servers
can start talking DOH, and they well might.  Resolvers can then speak it to
them. DNS has fundamentally changed.

And legally, auths can emit these 32 bit sized DNS messages now, so we'll
have to be able to store them in resolvers, and also serve them up when
requested. 

Next up, someone writes a testsuite for this and complains to all resolvers
and authoritative servers that they are not compliant.  Anyone implementing
a DOH-proxy (which seems to be common) is now also stymied since resolvers
can't communicate 32 bit sized DNS messages over any transport they do
support.

Whenever someone creates a new DNS feature, it turns into a requirement. And
it starts showing up in RFPs and mandatory feature lists. And we all have to
do it, or spend valuable time arguing with users and customers why they
don't actually need this. 

So with one sentence in a draft about a new transport format, for a feature
no one has yet found a usecase for, all DNS implementations will eventually
have to change or spend time arguing with their users.

Next up, we will have standards action work to determine the semantics of TC
on TCP/IP, because this will start to happen once authoritative servers
emit megabyte sized answers. This requires another new RFC and all resolvers
and stubs will have to learn how to deal with this. We may also have to
write a 32-bit TCP protocol perhaps so we at least have a lightweight way of
sharing large DNS answers.

Dave, you mention you aren't worried over this change. I assume this means a
strong commitment to implementing the changes in your software and working
on the drafts that specify the TC behaviour on TCP? 

Finally, I want to echo the remarks of Andrew that if we are going to change
30 years of DNS, it is a big thing.  And it should not come out of a privacy
enhancing transport format that is being rushed into service.

And frankly, for the people that do want to see a DOH RFC in 2018, I would
strongly suggest sticking to being a transport format that does not change
the rest of DNS.  Because I expect we'll be working on this well into 2019
if this WG wants to overhaul DNS as part of DOH.

	Bert