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

Dave Lawrence <> Sat, 09 June 2018 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB19C130DC0 for <>; Fri, 8 Jun 2018 17:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lSUf36GmID4c for <>; Fri, 8 Jun 2018 17:01:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5102D130DE5 for <>; Fri, 8 Jun 2018 17:01:58 -0700 (PDT)
Received: by (Postfix, from userid 102) id 9D12223F10; Fri, 8 Jun 2018 20:01:57 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Fri, 8 Jun 2018 20:01:57 -0400
From: Dave Lawrence <>
To: DoH WG <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Archived-At: <>
Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Jun 2018 00:02:00 -0000

bert hubert writes:
> First, we should be clear no one has identified a usecase for
> "megabyte size DNS messages" that can't be solved today already.  So
> the question is, for no identified upside, what is the downside?

First we should be clear that we have identified a use case of zone
transfers, and if you want to refute it then please be more clear on
what your objection to that use case is that makes it not legitimate.
Just hand-waving it away with "can be solved already" isn't really an
answer, since there are lots of ways we can solve problems but that
doesn't make them necessarily better.  It just means we're adaptable
in the face of adversity.

That rebuttal doesn't even yet have to address other potential use
cases that have been mentioned like increased cryptographic
information in messages, which could also benefit from not being
limited to 64k.

> Dave, you mention you aren't worried over this change. I assume this
> means a strong commitment to implementing the changes in your
> software and working on the drafts that specify the TC behaviour on
> TCP?

Sure, you bet.  Since existing software will already emit TC over
DNS/TCP you are absolutely correct that we should address that in
dnsop.  I look forward to working with you on that.

While you're here, can you please tell us what problems your code is
going to have with a > 64k message that you can't solve if there is no
defined limit on message size but that you could solve if there were?