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

Mukund Sivaraman <muks@mukund.org> Thu, 14 June 2018 20:12 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 1A6BA130EE0 for <doh@ietfa.amsl.com>; Thu, 14 Jun 2018 13:12:07 -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 MUtEf_71wcFW for <doh@ietfa.amsl.com>; Thu, 14 Jun 2018 13:12:04 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5B233130F4D for <doh@ietf.org>; Thu, 14 Jun 2018 13:12:03 -0700 (PDT)
Received: from jurassic (unknown [49.203.216.53]) (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 B081232C07B4; Thu, 14 Jun 2018 20:12:00 +0000 (UTC)
Date: Fri, 15 Jun 2018 01:41:55 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Puneet Sood <puneets=40google.com@dmarc.ietf.org>
Cc: doh@ietf.org
Message-ID: <20180614201155.GA27412@jurassic>
References: <CA+9_gVuGY8GLf+R4FONit9hweoEEFXOnh9WRVY_5Q5bbQi7bLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+9_gVuGY8GLf+R4FONit9hweoEEFXOnh9WRVY_5Q5bbQi7bLQ@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/T7fXGaMXPPv2M9KT-z_8ZjahOWQ>
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: Thu, 14 Jun 2018 20:12:08 -0000

On Thu, Jun 14, 2018 at 04:00:43PM -0400, Puneet Sood wrote:
> Reading draft 10 section 6.1, I do not see any text addressing
> interaction of the message size with the cache behavior in a recursive
> resolver.  This is mostly theoretical right now because the transports
> (UDP, TCP) between recursive and authoritative servers are constrained
> by the 64K limit. However when recursive resolvers start receiving >
> 64K responses, this will need to be addressed. Couple of points:
> 1. Will a caching resolver be expected to cache very large responses?
> An implementation may decide to put an upper limit on the size of a
> message it will cache.
> 2. Will a caching resolver need to cache different answers
> corresponding to the 64K limit and the "unlimited" case?

There's no use-case for any such caching. There's no data that DNS
carries that needs such large answers to be cached today. That "640k
ought to be enough for anybody" thing keeps coming up, but this is
over-engineering. It's like computing everything with bignums instead of
64-bit ints because.. who knows.. a larger number may come and we should
not restrict it because it's 2018.

		Mukund