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

Star Brilliant <m13253@hotmail.com> Tue, 05 June 2018 17:50 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 CC32513113B for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 10:50:15 -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 MZGg9kZScunu for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 10:50:14 -0700 (PDT)
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-oln040092012045.outbound.protection.outlook.com [40.92.12.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53000131154 for <doh@ietf.org>; Tue, 5 Jun 2018 10:50:14 -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=2OnVDyRiw15zjVmt5dTV3MDCYHKsFpp1H36WUPYUuMM=; b=RX8Y7fFhz3S+TH/baIkLtiQBsygslO0NFoiK6BzT4TZswNRBlWQX+k5iR07G11jFdibCbXAHftaDQo8zMsH3Tzmb04egAMcD/BYbosN1ZWZOmMeFWVpzF8Y7hDBkdAizti8/t37lKKNUsgY2pY9KaT/JNeVutGnAgmH38JyjRf8bl6eAjmH63WHdaoOWKw9Xji34Re+YT32nBCIJlP2lopE9nBTqyS2GcQLr93F3hCTOloVbqevRF0dPh4e8nHmB39sK4e0aKEb+/PYHOGWJlA0YvEPZdd+2xNqeTogdAWKHmDO4S6VM7nfBsL8uM+icM7wJXBAaAM98PNLv6jhpgg==
Received: from BY2NAM05FT013.eop-nam05.prod.protection.outlook.com (10.152.100.51) by BY2NAM05HT175.eop-nam05.prod.protection.outlook.com (10.152.101.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.841.6; Tue, 5 Jun 2018 17:50:13 +0000
Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.100.58) by BY2NAM05FT013.mail.protection.outlook.com (10.152.100.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.841.6 via Frontend Transport; Tue, 5 Jun 2018 17:50:13 +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 17:50:13 +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//5ho9S02KYza5xDwOp6RRtiwAgAAIrgCAAAVeAIAABIeAgAAO1QCAAAOGWIAADJIAgAAEt60=
Date: Tue, 05 Jun 2018 17:50:13 +0000
Message-ID: <BYAPR19MB2248B0ADD763FF82E8C6C2E194660@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> <BYAPR19MB22489BE90FE768BCB13BD40B94660@BYAPR19MB2248.namprd19.prod.outlook.com>, <alpine.DEB.2.11.1806051759430.1809@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.11.1806051759430.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:6A4992ED13DF1C49BB7E50F505FEE7897B729E1C30226E4601088CBFFBB0BE57; UpperCasedChecksum:B0884EBED9D95ED1722D443954C4C26C6AEA6E7719F738E89006B035291194BA; SizeAsReceived:7586; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [0IWTit2HrVuz7hhGzNiKDQdGrpQrao2M2AmrRi5UySvHG5SiUfXjDQ==]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2NAM05HT175; 7:EwHnV3pzNrbUynV7Y4DhaczpAwB6Qliq+4E9Gvp5p7+aKfNnk9VVpczdsPgYo+oH50msY+JCsf/55DTXB5nA9DyjtLITL9ekuvowl/bPfMR5WY2irhraL3V7mOIW9pLuePctAbV6UP86EmvB4+FBjwdmEGm6y/2ae1UMat+WWpMMfajwSg3ORVCL3C3B98OUMoHOLUMM4bDWSi4VVb4xHVr06PM8sBx1P6tYg7YD5FpSzexdXWlvW5yjEMPA9O55
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:BY2NAM05HT175;
x-ms-traffictypediagnostic: BY2NAM05HT175:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM05HT175; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM05HT175;
x-forefront-prvs: 0694C54398
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(52314003)(199004)(189003)(106356001)(20460500001)(486006)(2351001)(105586002)(73972006)(81156014)(8676002)(104016004)(1730700003)(3280700002)(3660700001)(8936002)(55016002)(102836004)(76176011)(6346003)(68736007)(93886005)(14454004)(6506007)(46003)(59450400001)(11346002)(446003)(2501003)(74316002)(305945005)(7696005)(6436002)(99286004)(5250100002)(5640700003)(2900100001)(97736004)(229853002)(82202002)(5660300001)(6916009)(6246003)(87572001)(9686003)(25786009)(86362001)(476003)(83332001)(33656002)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM05HT175; 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: Ivjige+5Dt5AcCP6Xmkh7NjnrmkDoj7lgvQzSZDHojxd+mw8amueFZ24Fls/HFCyuQgxEWSSbtxCwJiXQ+rIQI0EnmhMiTxBiVTLrqU0sg0kRtpciMGDPBM5RntwQNqSB3b84du23J2hZQbezmilHqkBM2IpMLdTF0bX60Jm8MccuBpIcAuO1edPFQ2OvRLv
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 17a0616b-385e-4c00-1ae6-08d5cb0cca2c
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-Network-Message-Id: 17a0616b-385e-4c00-1ae6-08d5cb0cca2c
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2018 17:50:13.4267 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM05HT175
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/TEEoKTFBkWmpNXBUvmkeja2pF5k>
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 17:50:22 -0000

Tony Finch <dot@dotat.at> wrote:

> If a DoH server talks to an upstream resolver over a truncating transport,
> the DoH server has to retry over a non-truncating transport.

I agree. But obviously you did not read my message well.
A DoH server should retry over TCP.
I am only talking about the last resort, when TCP does not work or still returned TC.


> They are all broken and don't implement the protocol correctly.

As we know, the browser that can render broken HTML tag soup wins the battle.
That's the same with DNS. If you are not compatible with broken implementations, users will not use your product.
Our code don't produce garbage, but we need to consume garbage produced by others, right?
So please don't make excuses for your writing less compatibility code (in case if so).


> The point of this discussion is what the client is supposed to understand
> by TC in a response. RFC 1035 implies that (over TCP) TC must not be set
> by a server and must be ignored by a client. DoH should be the same.

The DoH client does not need to understand the TC bit. It just pass the TC bit to downstream.
Let me explain how this work:

When the downstream finds the TC bit, it should retry with TCP to the DoH client.
And the DoH client should return the exactly same answer with TC.
The downstream should stop retrying with the second TC (since there are no more methods to retry).

I think it makes sense.


> My trivial DoH code makes upstream queries over TCP, so the EDNS buffer
> size is ignored.

Just a friendly warning:
I have done this thing in my productive server, and soon get banned by some authoritative servers.
Most authoritative servers on the Internet are really really fragile.
Anyway, it's okay to use full TCP, if you don't do recursion yourself.


And in case if I misunderstood... Could we make this discussion less gunpowder-smelly and more kind?