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

Patrick McManus <pmcmanus@mozilla.com> Fri, 08 June 2018 09:34 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 E43D6130E50 for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 02:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 H8vzqfCoSFcv for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 02:34:24 -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 CCD55130E54 for <doh@ietf.org>; Fri, 8 Jun 2018 02:34:23 -0700 (PDT)
Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 54F403A081 for <doh@ietf.org>; Fri, 8 Jun 2018 05:34:21 -0400 (EDT)
Received: by mail-oi0-f41.google.com with SMTP id t133-v6so11246077oif.10 for <doh@ietf.org>; Fri, 08 Jun 2018 02:34:21 -0700 (PDT)
X-Gm-Message-State: APt69E1gWUHIoTfbN9npN7TcWlkKJ+i31l8GMlM2YpTzLaNh42pHk6I2 2v1DGwSbtbGx9wcIY1i6eKln3TVfngU+jpzoBt8=
X-Google-Smtp-Source: ADUXVKLt1g3ZTAQiVObdZ6+BLuJH5wgeLLVUvibtcR4P+YybEEIvsyRLyiEF3X3feZzz9uU7Z1AvYctGUYxhmNC4Ntw=
X-Received: by 2002:aca:f288:: with SMTP id q130-v6mr2560414oih.347.1528450460959; Fri, 08 Jun 2018 02:34:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 02:34:19 -0700 (PDT)
In-Reply-To: <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> <20180607215851.GA32738@server.ds9a.nl>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 8 Jun 2018 11:34:19 +0200
X-Gmail-Original-Message-ID: <CAOdDvNqNpZ8fKPCO5sEqjROBHjg4wx-GGPMYSSynode10jeC0Q@mail.gmail.com>
Message-ID: <CAOdDvNqNpZ8fKPCO5sEqjROBHjg4wx-GGPMYSSynode10jeC0Q@mail.gmail.com>
To: bert hubert <bert.hubert@powerdns.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Dave Lawrence <tale@dd.org>, DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c85f91056e1e1ae9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/BUqMBpr47AsCsfKzsrTVNeNF1QA>
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 09:34:26 -0000

I'm not on board with limiting a 2018 protocol to 64KB variants because
some parser of some some format might have a bug. At the very least we need
to be more specific so we can assess the scope of the interoperability
issue. DoH opens up new things - that's a good property. Not everything
will be gatewayed back and forth into wireformat, and the wireformat isn't
inherently limited to 16bit either. AXFR is an especially interesting case
for DoH because it supports multiplexing and priority between streams, it
might actually be the best way to carry it.

as for other formats they are coming. Paul has an informational draft that
has been sent to the IESG:
https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/ and I've heard
rumors of others in the works - even from the dns community :)

If there is a known problem with gatewaying between formats, that's worth
some non normative text to mention - but the notion that 64KB is enough for
anybody is one I want to push back on. Even for that I would appreciate a
citation of where the problem lays - there isn't agreement that wireformat
actually has such a limit (though its existing transports do and maybe
that's what should be noted), and no particular implementation choices,
much less widely deployed and hard to upgrade implementations, have been
cited (again - I'm not saying they don't exist.).

-Patrick

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

> 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
>