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

Patrick McManus <pmcmanus@mozilla.com> Thu, 07 June 2018 14:17 UTC

Return-Path: <pmcmanus@mozilla.com>
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 B237B130EF1 for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 07:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level:
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 B7CFSR_tujSP for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 07:17:33 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB0130EF7 for <doh@ietf.org>; Thu, 7 Jun 2018 07:17:33 -0700 (PDT)
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id 662FB3A05A for <doh@ietf.org>; Thu, 7 Jun 2018 10:17:32 -0400 (EDT)
Received: by mail-oi0-f48.google.com with SMTP id f79-v6so8752496oib.7 for <doh@ietf.org>; Thu, 07 Jun 2018 07:17:32 -0700 (PDT)
X-Gm-Message-State: APt69E1UIhDRS3fjjVi7lGm738WSQBHims+5dTkPU3nupw3qdaRL3W1G UpTlwS7tm5qWOrVT0NaGIa8KhyD7MgUMYZ78+Lw=
X-Google-Smtp-Source: ADUXVKLb31vnsmsHyB+KGEThe9gITbr5ACWycblc9ZDpSUXVzZrDs88gVhLlmkJr/oLxpDHao98ZyTXw/DGQIwuUcmc=
X-Received: by 2002:aca:f3c5:: with SMTP id r188-v6mr676260oih.17.1528381052138; Thu, 07 Jun 2018 07:17:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 07:17:31 -0700 (PDT)
In-Reply-To: <20180607093647.GB32326@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>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Thu, 7 Jun 2018 16:17:31 +0200
X-Gmail-Original-Message-ID: <CAOdDvNriZDjU9yqUQjqN4fO84ENPWO3si-QePiKRgt+7VJVK0g@mail.gmail.com>
Message-ID: <CAOdDvNriZDjU9yqUQjqN4fO84ENPWO3si-QePiKRgt+7VJVK0g@mail.gmail.com>
To: bert hubert <bert.hubert@powerdns.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Paul Hoffman <paul.hoffman@icann.org>, DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b1c771056e0df174"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/-dDMctFB1yWop2H2l4cx7dp9Dqw>
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 14:17:36 -0000

On Thu, Jun 7, 2018 at 11:36 AM, bert hubert <bert.hubert@powerdns.com>;
wrote:

> On Thu, Jun 07, 2018 at 09:19:06AM +0200, Patrick McManus wrote:
> > it seems possible that this is a property of the default media type not
> of
> > DoH. e.g. a negotiated json response wouldn't have this kind of
> limitation.
> > Does that make sense?
>
> Firstly, it is not a media type limitation. It is a question of if we want
> to extend DNS into a territory where it has never been before. The moment
> 100 kilobyte DNS answers become possible, we need to redo a ton of
> software.
> This is true if the end transport is JSON or a DNS message wrapped into an
> HTTP response.
>
>
I still think that your argument only applies to the *wireformat media
types.

New types mean new parsers. It seems your concerns are about existing
parsers that, by definition, can't parse the new types. So I'm not
concerned about them with new types.


> Before typing a lot more characters on this, can I ask who is actually
> arguing that we need bigger DNS messages?  Who is hurting under the 65536
> byte constraint?  DNS over HTTPS implies that we have access to HTTPS.
> This
> protocol supports messages as large as you want.
>
>
I don't want to constrain what those new types might do based on our
current understanding. For instance some media types might be very space
inefficient but super efficient to access.. and we might fix that on the
wire with a http compression encoding. heck maybe they come back as jpeg
visualizations; I'm not here to judge.

If we buy my argument then we don't so much as restrict DoH as note that
the wireformat media types effectively have this limitation already that
needs to be respected.