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

Mukund Sivaraman <muks@mukund.org> Wed, 13 June 2018 20:56 UTC

Return-Path: <muks@mukund.org>
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 EE124130F6F for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 13:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable 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 UvDrNH44T9uf for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 13:56:46 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD68130F7E for <doh@ietf.org>; Wed, 13 Jun 2018 13:56:46 -0700 (PDT)
Received: from jurassic (unknown [14.194.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id E724332C0972; Wed, 13 Jun 2018 20:56:42 +0000 (UTC)
Date: Thu, 14 Jun 2018 02:26:37 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: petr.spacek@nic.cz, DoH WG <doh@ietf.org>
Message-ID: <20180613205637.GA23215@jurassic>
References: <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> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <CAHbrMsBoKE-pfz97ZDb9ReLKMedk2KJ7xLCw_MPmxVtqF7PcuA@mail.gmail.com> <20180613192030.GA2792@jurassic> <CAHbrMsACdaz13v=2jbpZq1RU-_CP36Cgz13iFFWVj8qrjQ0b=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHbrMsACdaz13v=2jbpZq1RU-_CP36Cgz13iFFWVj8qrjQ0b=g@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/VIAy4MLyqzTFax70hTjQ9W2WOUY>
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 20:56:50 -0000

On Wed, Jun 13, 2018 at 03:43:44PM -0400, Ben Schwartz wrote:
> Snipped to focus on one technical point.
> 
> On Wed, Jun 13, 2018 at 3:20 PM Mukund Sivaraman <muks@mukund.org>; wrote:
> 
> > Large zone transfers are supported today using TCP continuation messages
> > and the same can be encoded by DoH within the 64kB message limit.
> 
> 
> This is currently not true, because each DoH query must return at most a
> single DNS message in the response.  Therefore, there is no way to make use
> of continuation messages in DoH.  I think this is a major reason why we are
> having this conversation: lack of continuation messages renders DoH
> strictly less expressive than standard DNS, which is a concern for gateway
> applications.

I meant it can be encoded by DoH within the 64kB limit as multiple
messages by using a multi-part scheme, instead of extending the DNS
message size. If the above is the concern, then this is the most
interoperable way. Changing DNS message boundaries isn't always doable.

Let me also be the devil's advocate. If the idea is to have more
flexible DNS messages that modern parsers can parse and reframe for
traditional DNS, why limit ourselves? Throw away the DNS message format
with redundant owner names of individual RRs, possibility of TTL
mismatch within RRset, no defined ordering of RRs, which has become
horrible already with hacks like OPT, and other things that make parsing
horrible. Make a clean new message format that encodes and decodes from
traditional DNS message format. I'd prefer that to increasing the
message size which is neither here nor there.

> Before someone pedantically points out this, AXFRs are sent as DNS QUERY
> > but they're not a DNS query in the layman's sense and the charter isn't
> > talking about the opcode. :P
> >
> 
> Without veering into charter interpretation, I agree that supporting AXFR
> is distinctly lower priority than typical client-recursive queries.
> However, some working group participants believe that it would be valuable,
> so it's worth considering if there is a reasonable way to include support
> for it, or to leave open the possibility of future support.

On the topic of charter, my interpretation on reading it is that DoH
will be used to configure a stub resolver when other traditional DNS
transports are tried and will not work, as a means to keep things going.

DoH is not even an RFC yet and there has been an announcement from
Mozilla that by default all its DNS queries will be sent to Cloudflare
via DoH, and this is the default behavior that's all within the Firefox
application. Is anybody else concerned about the Firefox DoH
announcement?

Apart from the privacy implications, the fact that a browser used by
millions with a large market share is switching suddenly to a new
protocol at the application layer, that nobody except one or a handful
of cloud providers are ready for is unnerving.

It seems to be the first major use and it seems quite different from the
charter of DoH. Who is this serving? What will be some typical patterns
of using DoH?  Is DoH a fallback to a transport when traditional DNS
won't work, or is it supposed to become the new way of doing DNS, i.e.,
DNS 2.0? The concerns about what the purpose of DoH is and how it
compares to traditional DNS are not unjustified.

		Mukund