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

"Hewitt, Rory" <rhewitt@akamai.com> Wed, 06 June 2018 16:07 UTC

Return-Path: <rhewitt@akamai.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 AFBFA130F6F for <doh@ietfa.amsl.com>; Wed, 6 Jun 2018 09:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 Rf4fueOYQ-UT for <doh@ietfa.amsl.com>; Wed, 6 Jun 2018 09:07:08 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A13B3130F66 for <doh@ietf.org>; Wed, 6 Jun 2018 09:07:08 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w56G6XIh029581; Wed, 6 Jun 2018 17:07:07 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=dRfKShHj9fAc68U4dXiuRr5u+HRy+/bwhriFkrYez8I=; b=D+Kv7hNvs34WTGwQyQFNVKeq0fTD01PKOU4SV5he3jos/6C2yYP41a7uhKrzM/Qe46in hWNANlvesidAR2Ou3qiGs+WmkXmWTno70VoZ4iqpO5g3ENy3kZO0qb/XRGJGxUZPcrlo sv/5tQHFJb2G2v9dJw1iaFVl3GGsiXOR7o7dTn3o2Sg+ZC+yuvs9aqVhD5IzDIYL2mnW qdwZf31y92522CkaxJj5w2U/jvKj9zp6w8rk80Vmx3QkoiaSxlkSo/dQbW43HCFQv8Aw FS5634oXuEXP+q2d+LyKZHURHX1bQwmChwmhxfNpFEts3K+a2ZfCXYYwCfD5+TSWuUbr 4g==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2je97wab3c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 17:07:07 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w56G6A56018465; Wed, 6 Jun 2018 12:07:06 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2jbpjw3qub-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 12:07:06 -0400
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 6 Jun 2018 11:07:05 -0500
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1365.000; Wed, 6 Jun 2018 11:06:59 -0500
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: Petr Špaček <petr.spacek@nic.cz>, "doh@ietf.org" <doh@ietf.org>
Thread-Topic: [Doh] DNS Camel thoughts: TC and message size
Thread-Index: AQHT/XlIweVnVgymmkuvmY5C/GuZb6RTm14AgAAA2oD//8lloA==
Date: Wed, 06 Jun 2018 16:06:58 +0000
Message-ID: <2444368b1a6543cc9aff67317e9ab82a@ustx2ex-dag1mb3.msg.corp.akamai.com>
References: <20180606093212.GA23880@server.ds9a.nl> <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <35969d8d-c64d-86a6-9edb-0bbe8f2863d6@nic.cz>
In-Reply-To: <35969d8d-c64d-86a6-9edb-0bbe8f2863d6@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.113.63]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00F9_01D3FD75.B8BC3760"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806060183
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806060183
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/HnnG6HRhv8MxKdJOT45v6ez-nK0>
Subject: Re: [Doh] 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 16:07:14 -0000

+1 from me also. Thanks Tony & Bert (and Star!) for narrowing in on an elegant solution, wording-wise.

Thanks,

Rory

-----Original Message-----
From: Petr Špaček [mailto:petr.spacek@nic.cz] 
Sent: Wednesday, June 6, 2018 7:22 AM
To: doh@ietf.org
Subject: Re: [Doh] DNS Camel thoughts: TC and message size

On 6.6.2018 16:18, Tony Finch wrote:
> bert hubert <bert.hubert@powerdns.com> wrote:
>>
>> So, the DNS Camel has a suggestion. Specify that DNS messages carried 
>> over DOH can be up to 65536 bytes large and note that truncation 
>> should be handled as if the response was carried over TCP/53.
>>
>> Effectively this means that a TC response over DOH is almost always 
>> useless, but this is no loss of functionality since it did not work 
>> over TCP/IP either. We've not made anything worse here.
>>
>> And in general this is what I hope that DOH will restrict itself to: 
>> provide access to the DNS protocol over HTTPS and not change DNS itself.
> 
> Full agreement, and with the rest of your message. Thanks for writing 
> it so that I didn't have to!
> 
> I think the semantics of a DNS message transported over HTTPS should 
> be the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, 
> and so forth.

I totally agree with Bert and Tony, thank you for an excelent summary!

--
Petr Špaček  @  CZ.NIC

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh