Re: [Doh] [Ext] a tad confused on response sizes

Star Brilliant <m13253@hotmail.com> Tue, 05 June 2018 16:44 UTC

Return-Path: <m13253@hotmail.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 3152C126CB6 for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 09:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.875
X-Spam-Level:
X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 vit5cljSzljX for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 09:44:01 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-oln040092008035.outbound.protection.outlook.com [40.92.8.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FA912D949 for <doh@ietf.org>; Tue, 5 Jun 2018 09:44:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ogFJ76F0xm1r1u6ZSLV27UbPmUwHQ/QDeMoQSY4EbY=; b=QH+OIwYI0K6B+jgmVhHSm+Pd+Gr2SlZ792Vcm6dwig0a0oxbtpzazE1l2uP92qwFFVaauHYFWTQUMLMAe/+EeoWfvYuFQqGMM6pyfN0RfRAwsPxuL/xhgDC3d7ZtuWxA+3AY8c5WDpeHIWC+Z4YHLSdzz0sjPEPQBHlJfl6faGhjcgBjhKOB9ijCI/mK1jvrmGetcK7hCBS2p/Z9ZZsHs0+ViTI/Q1DRSp3fjSWs6aSQxqGw0CmCoe0PWsdNDEbhzc00sj0FUfwd+OzY6ypmycDDgju1o9V600hyNwG2cM4s/SP5vJhDPMOke4esopjr2NebxHOPL8Gf29dPuhw6yA==
Received: from DM3NAM03FT007.eop-NAM03.prod.protection.outlook.com (10.152.82.56) by DM3NAM03HT186.eop-NAM03.prod.protection.outlook.com (10.152.83.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.755.15; Tue, 5 Jun 2018 16:43:59 +0000
Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.82.59) by DM3NAM03FT007.mail.protection.outlook.com (10.152.82.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10 via Frontend Transport; Tue, 5 Jun 2018 16:43:59 +0000
Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb%4]) with mapi id 15.20.0820.015; Tue, 5 Jun 2018 16:43:59 +0000
From: Star Brilliant <m13253@hotmail.com>
To: "doh@ietf.org" <doh@ietf.org>
Thread-Topic: [Doh] [Ext] a tad confused on response sizes
Thread-Index: AQHT/NdXdt//5ho9S02KYza5xDwOp6RRtiwAgAAIrgCAAAVeAIAABIeAgAAO1QCAAAOGWA==
Date: Tue, 5 Jun 2018 16:43:59 +0000
Message-ID: <BYAPR19MB22489BE90FE768BCB13BD40B94660@BYAPR19MB2248.namprd19.prod.outlook.com>
References: <20180605120510.GA29047@server.ds9a.nl> <CFEAAD6E-4F9D-4DB5-A362-21775D74F84A@icann.org> <alpine.DEB.2.11.1806051515510.1809@grey.csi.cam.ac.uk> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <alpine.DEB.2.11.1806051604150.1809@grey.csi.cam.ac.uk> <20180605152355.6tlbeqvt7luklwjl@nic.fr>, <alpine.DEB.2.11.1806051710290.1809@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.11.1806051710290.1809@grey.csi.cam.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:3DD783BB72AC6211D51E9B3F533601222AC0F053D57A172996B18D01D39555FB; UpperCasedChecksum:1DD7F15C34037186FCE7870F43CB050FA523199F01C70DE264CD5930AEB3B3D8; SizeAsReceived:7422; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [e6yGR1CoqOPZZqhCpDg39E/Fj2WHAMsnhM8+3ZrcMoi7IcACP7tm8g==]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM3NAM03HT186; 7:U7BKNy/5gLpIQh/WQaRua9ZPHM01htkqiInbvjwFZPwM/weURl4hchrvPOtz9S7QhxADsCoENMbCyx6C6Vgpp7bDursoC86XyCKgAVjhGmMB7eoj6rILQX00REcd3IAUy4UeM8EaaisD6AViM5Ic0dgKFPO/i2UbHFI15qQJ1vgQhx4nurSd8DHUC0xTrwlDEP3gMzNpkGJurIIq8ssEs9RolYRMq8JvjQT7ropHMpEsHTzz8FDvxNdqSBUCC/gL
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:DM3NAM03HT186;
x-ms-traffictypediagnostic: DM3NAM03HT186:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:DM3NAM03HT186; BCL:0; PCL:0; RULEID:; SRVR:DM3NAM03HT186;
x-forefront-prvs: 0694C54398
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(6916009)(5640700003)(9686003)(73972006)(33656002)(6246003)(106356001)(55016002)(105586002)(305945005)(5660300001)(74316002)(25786009)(82202002)(97736004)(8936002)(81156014)(14454004)(486006)(104016004)(83332001)(6506007)(46003)(87572001)(93886005)(476003)(20460500001)(1730700003)(3280700002)(11346002)(2900100001)(5250100002)(8676002)(86362001)(7696005)(3660700001)(229853002)(102836004)(6346003)(99286004)(76176011)(68736007)(2501003)(6436002)(446003)(2351001)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM03HT186; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:;
received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com;
x-microsoft-antispam-message-info: PIOPkeQ0Eor1qsUGFyPDffKJ0JRNrN5BIINF/EeazdWUeg8z85kR3AYYNxjKXIo1hdT7AwawFGJ1Imyht59VOt4AbfFI1aTDqOWWjLTlKkW5acS+mNBPGqL5ZvbKEZy+iQ+R+3AORn8kg20HOWYL8Rn1hQBNY2oZTks5uW9Fk3DqYaJ22VaYDuINrCe+rs1N
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 7454a594-6e41-4455-d3fc-08d5cb038997
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-Network-Message-Id: 7454a594-6e41-4455-d3fc-08d5cb038997
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2018 16:43:59.6132 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT186
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/zoVdMtAo3tG8sTbrqkYJt6lKyC8>
Subject: Re: [Doh] [Ext] a tad confused on response sizes
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: Tue, 05 Jun 2018 16:44:02 -0000

Tony Finch <dot@dotat.at>; wrote:
> Since https's permitted length is longer than a DNS message,
> it is invalid for a DoH server to truncate.

No, DoH server never truncates messages.
It is the upstream server that truncates the message.

> RFC 1035 doesn't allow TC for TCP messages.

The fact is that there are TCP servers that do truncates messages.
There are also servers that firewalls TCP by mistake so only UDP could pass.
Some of them are even authoritative server that you have no other ways to bypass.

So here is the question: what should you do if you received a TC from a TCP upstream?
I run massive deployment of DoH server, and I see this kind of packets quite often.

Yes, we know it is not RFC1035-compliant. But what can a DoH server do with this kind of malformed packet?
1) Ignore the TC bit and return the truncated answer to DoH client?
2) Take the TC bit and return the truncated answer to DoH client?
3) Return SERVFAIL and persuade users to give up your DoH service?
4) Return HTTP 500 / 502 / 503 to mislead users that your server crashed?
5) Throw a Segfault with a pretty-printed stacktrace in your syslog?

You could do nothing but keep the TC bit. That is why DoH allows TC bit.

TL;DR: It's not the DoH server that truncates. It's somebody else truncates and DoH could do nothing (even with TCP) to fix it.