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 19:20 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 5697612426A for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 12:20:44 -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=ham 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 hmGoiK0WN3a9 for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 12:20:42 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id E737F130E8A for <doh@ietf.org>; Wed, 13 Jun 2018 12:20:41 -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 5E54532C0972; Wed, 13 Jun 2018 19:20:36 +0000 (UTC)
Date: Thu, 14 Jun 2018 00:50:30 +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: <20180613192030.GA2792@jurassic>
References: <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHbrMsBoKE-pfz97ZDb9ReLKMedk2KJ7xLCw_MPmxVtqF7PcuA@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/HsG1COK8HOcOzo32DGHh6dxmOrw>
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 19:20:45 -0000
On Wed, Jun 13, 2018 at 02:16:11PM -0400, Ben Schwartz wrote: > > I think Ray was too shy to ask The Question: > > > > Is the goal of the current doh WG > > > > a) "standardize encodings for DNS queries and responses > > that are suitable for use in HTTPS. This will enable the domain name > > system to function over certain paths where existing DNS methods (UDP, > > TLS [RFC 7857], and DTLS [RFC 8094]) experience problems." in an > > interoperable way, i.e. doing a thing the WG was chartered to do? > > > > OR > > > > b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the > > original DNS protocol? We badly need DNS 2.0 so let's admit that, it is > > not a shame. > > > > I appreciate your concern but please try to avoid accusing members of the > working group of trying to hide anything. It's a valid question that has been asked. Many of us are concerned about things are being said and it's best to discuss them freely without taking offense. This is from Tale's post: > There are already indications from people who want to leverage it to > provide DNS response delivery without involving the traditional > resolution path. Some of them stated quite clearly at the first DoH > BoF that they really weren't even interested in working on it if it > was just going to be merely a tunneling protocol. > > It isn't clear to me how you could meaningfully restrict it from being > a "'first class' transport". Fiat declaration sure wouldn't do it. This may well fit in within current DoH charter or may not, depending on how "existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience problems" from the charter is interpreted. Is this a replacement for traditional DNS? (there's no need to take offense at this question.. please let's just discuss it.) The 64kB limit is just one aspect (we've been asked for proof of problems - it has been explained already that DNS message parsers do it in memory currently - 64kB imposes an implicit upper limit on the derived objects in in-memory message structures (lists of names + RDATA objects). E.g., a 32-bit limit would mean the possibility of requiring to hold 4GB wire data in memory and the larger derived structs from parsing it, or, reimplementing message parsing with disk storage. (Think of sax vs. DOM XML parsing for an analogy.) > The question of what message size limits to require or recommend does not > resemble an attempt at any kind of "DNS 2.0". Note that message size > interoperability questions are not a new issue within the DNS: many > endpoints will reject messages larger than 4K or 8K, even though there is > no way to signal this limitation. HTTP has similar issues (e.g. URL length > limits). Implementators are concerned because this 64kB limit has been assumed forever now and various parts of code aren't written or even designed to handle larger sizes. I don't know how you mean by "endpoints will reject messages larger than 4k".. I think any of the popular open source DNS nameservers will parse 64kB messages over TCP (though some may not generate > 16kB messages as name compression pointers have a limit of 16kB from the start). > The charter does not require that the standard guarantee functionality in > all possible use cases and multi-system interactions, and both choices (to > apply a limit or not) fail to serve a desirable use case: either we don't > support 100% reliable gateways from DoH into DNS-over-TCP, or we don't > support large zone transfers over DoH. It's up to the working group to > balance these concerns, either by choosing one option or by finding a > middle ground. The charter says: "The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS clients (e.g., operating system stub resolvers) and recursive resolvers." and "Specification of how DNS-formatted data may be used for use cases beyond normal DNS queries is out of scope for the working group." and we're talking about zone transfers. Zone transfers are not DNS queries. So what's the limit of this charter? Large zone transfers are supported today using TCP continuation messages and the same can be encoded by DoH within the 64kB message limit. FWIW, even we don't use larger than 16kB messages for zone transfers in traditional DNS because it doesn't compress well, though there is a 64kB budget. If DoH is purely an encoding transport to carry traditional DNS messages, then there will be a problem with larger than 64kB messages from: (1) tradtional NS -> (2) trad:DoH intermediate using 1MB messages -> (3) DoH client and: (1) DoH NS using 1MB messages -> (2) DoH/trad intermediate -> (3) traditional client because TSIG will not validate if only (1) has the secret to generate them and (2) is just a forwarder. A person like me is wondering about these things, because I don't know what's the limit for DoH - how all it will be used, because of everything that's being discussed. It appears that DoH will not be restricted, so before rushing to update things, please discuss traditional DNS's concerns, and also discuss what's within scope in the charter. As an exercise, it'd be good to read about several practial usage patterns in which DoH may be used. Mukund
- Re: [Doh] Are we missing an architecture? (was Re… Patrick McManus
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Puneet Sood
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ted Lemon
- Re: [Doh] [Ext] Are we missing an architecture? (… Ted Lemon
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ted Lemon
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Mateusz Jończyk
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Sara Dickinson
- Re: [Doh] [Ext] Are we missing an architecture? (… Daniel Stenberg
- Re: [Doh] [Ext] Are we missing an architecture? (… Sara Dickinson
- Re: [Doh] [Ext] Are we missing an architecture? (… Daniel Stenberg
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ray Bellis
- Re: [Doh] [Ext] Are we missing an architecture? (… Patrick McManus
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ben Schwartz
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ben Schwartz
- Re: [Doh] [Ext] Are we missing an architecture? (… Petr Špaček
- Re: [Doh] [Ext] Are we missing an architecture? (… Ray Bellis
- Re: [Doh] [Ext] Are we missing an architecture? (… bert hubert
- Re: [Doh] [Ext] Are we missing an architecture? (… Ray Bellis
- Re: [Doh] [Ext] Are we missing an architecture? (… Dave Lawrence
- Re: [Doh] [Ext] Are we missing an architecture? (… Dave Lawrence
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Tom Pusateri
- [Doh] DNS Camel thoughts: TC and message size bert hubert
- Re: [Doh] DNS Camel thoughts: TC and message size Petr Špaček
- Re: [Doh] DNS Camel thoughts: TC and message size Tony Finch
- Re: [Doh] DNS Camel thoughts: TC and message size Hewitt, Rory
- Re: [Doh] DNS Camel thoughts: TC and message size Benno Overeinder
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… George Michaelson
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Paul Hoffman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Tony Finch
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… bert hubert
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Paul Hoffman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Martin J. Dürst
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Paul Hoffman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Tony Finch
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Ray Bellis
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Ray Bellis
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… bert hubert
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Robert Edmonds
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mateusz Jończyk
- [Doh] AXFR as several messages Re: [Ext] DNS Came… bert hubert
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… John Dickinson
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Ray Bellis
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mukund Sivaraman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mukund Sivaraman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Tony Finch
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Martin Thomson
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mark Nottingham
- [Doh] DNS Camel thoughts: TC and message size Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Ólafur Guðmundsson
- [Doh] Are we missing an architecture? (was Re: DN… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… bert hubert
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] Are we missing an architecture? (was Re… Mark Nottingham
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mukund Sivaraman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] Are we missing an architecture? (was Re… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] Are we missing an architecture? (was Re… Dave Lawrence
- Re: [Doh] Are we missing an architecture? (was Re… bert hubert
- Re: [Doh] Are we missing an architecture? (was Re… Dave Lawrence
- Re: [Doh] [Ext] Are we missing an architecture? (… Ray Bellis