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

Tony Finch <dot@dotat.at> Thu, 07 June 2018 10:33 UTC

Return-Path: <dot@dotat.at>
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 12757130EE7 for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 03:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 S2RG9YWRZ1hi for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 03:33:24 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC50C130ED2 for <doh@ietf.org>; Thu, 7 Jun 2018 03:33:23 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:34226) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQsEL-000MGb-eT (Exim 4.91) (return-path <dot@dotat.at>); Thu, 07 Jun 2018 11:33:21 +0100
Date: Thu, 7 Jun 2018 11:33:21 +0100
From: Tony Finch <dot@dotat.at>
To: Paul Hoffman <paul.hoffman@icann.org>
cc: DoH WG <doh@ietf.org>, bert hubert <bert.hubert@powerdns.com>
In-Reply-To: <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org>
Message-ID: <alpine.DEB.2.11.1806071121350.1809@grey.csi.cam.ac.uk>
References: <20180606093212.GA23880@server.ds9a.nl> <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Lnrito6HqXAXhtDEpY1hx-L26vs>
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: Thu, 07 Jun 2018 10:33:28 -0000

Paul Hoffman <paul.hoffman@icann.org>; wrote:
>
> 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;

The restriction comes from the 2 octet message length field, RFC 1035
section 4.2.2.

> 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.

Right. You need to make a distinction between RR data size limits and
message size limits. As you say, it's easily possible for an RRset to be
too long to fit in a message.

If a single RR doesn't fit in a message then it isn't possible to create
it via UPDATE or transfer it via AXFR/IXFR, though it can be represented
in master files.

It's clear such large RRs are not supported by the standards - I guess
they don't specify how to cope because huge RRs are an obviously lunatic
idea ;-)

> So, if this WG puts such a limitation in DOH, we are adding a
> restriction to DNS messages that is not currently in DNS-over-TCP, even
> though it is a "sensible" restriction.

No, the message size limit was always there, even though it is smaller
than the RR data size limit. This was the point of Bert's message.

As he said, lifting the 64K limit means "almost every DNS parser in
existence has become obsolete or at least untested! No DNS message larger
than 64KB has ever been possible."

>    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].

EDNS buffer sizes need to be handled the samee as for TCP as well.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
Shannon, Rockall, Malin, South Hebrides: Northerly or northeasterly, 3 or 4,
occasionally 5 later. Slight or moderate. Mainly fair. Moderate or good,
occasionally poor.