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

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 06 June 2018 22:55 UTC

Return-Path: <ajs@anvilwalrusden.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 28370130DE6 for <doh@ietfa.amsl.com>; Wed, 6 Jun 2018 15:55:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=C9q9xgXg; dkim=pass (1024-bit key) header.d=yitter.info header.b=lsvTe52E
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 frdjMqFTrqp5 for <doh@ietfa.amsl.com>; Wed, 6 Jun 2018 15:55:56 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5E31277C8 for <doh@ietf.org>; Wed, 6 Jun 2018 15:55:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id B83ECBDEF9 for <doh@ietf.org>; Wed, 6 Jun 2018 22:55:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528325725; bh=AkydS5HlWV9FGh0R5ushbgEQ01wp7DN6GAVLmlxASuc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=C9q9xgXgPOILBwAedXKAuPdA0ZraZ7cjMp6G7u5GjzBPnvzXN5Qv7XMuLeUdRtVQJ DjtuFrsJ5Px+aXka2LAsIs4fsm9odbLDjM+Nu+QESdfxFp8+Ya7/voicm+SbSdnYsN Dftct8lbNXf0lF7VR3B718zh4Vjw2+trvoCIC1U4=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20uSmmNU4SJk for <doh@ietf.org>; Wed, 6 Jun 2018 22:55:24 +0000 (UTC)
Date: Wed, 6 Jun 2018 18:55:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528325724; bh=AkydS5HlWV9FGh0R5ushbgEQ01wp7DN6GAVLmlxASuc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=lsvTe52E6PzE9lebyRW2T/JaXLPkmXCpJEuhknl5WMfpp9oXFC/cpi7uY3DVwbrU5 3uneUvqZbRpgG8jVu8bhmZJYUY5t23zIAX9xgqwaB8KwFrrOVcGMevJO8To/Y3H0CU riO7WrRUyZeRrRw+NKJNY/+FsfA25x+uo5snVGhU=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: doh@ietf.org
Message-ID: <20180606225522.GK2853@mx4.yitter.info>
References: <20180606093212.GA23880@server.ds9a.nl> <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/dtzleLFYEkyjSbDqcJ_7Hhl-Lx4>
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: Wed, 06 Jun 2018 22:56:00 -0000

Hi,

On Wed, Jun 06, 2018 at 10:42:08PM +0000, Paul Hoffman wrote:

> Three people agreed with this statement. DNS-over-TCP is defined in RFC 1035 and significantly updated in RFC 7766. Unless I'm missing something, neither of those document support the 65535 length restriction; in fact, RFC 1035 section 3.3.10 indicates that restriction doesn't exist because a response with a single maximally-sized NULL Rdata record could be slightly longer than that, and there is no restriction on how many NULL records can be in the RRset. Such a message could not use name compression into the a section beyond the Answer in that message. Similarly, there is no restriction on the total length of a TXT record. Having such records is clearly a bad idea, but they are not prohibited by the specs.
> 

This sounds actually like a long-unnoticed erratum in RFC 1035,
because I _think_ Bert's calculation is correct that there is as of
now no interoperable way to send a single message longer than 65535
octets, because of limits in the protocol (I haven't thought about it
in detail, but it immediately struck an "exactly" chord with me so I
have confidence).  I agree, however, that it's not a job for this WG
to fix.  Therefore,

>    DNS message truncation and the use of the TC bit should
>    be handled as if the response was carried over DNS
>    in TCP as defined in [RFC7766].

I'm ok with this, and I also suspect that an erratum (admittedly not a
simple one) on either 1035 or 7766 would be enough to close this hole.

Best regards,

A
-- 
Andrew Sullivan
ajs@anvilwalrusden.com