From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id BC1292F048 for ; Fri, 13 Sep 2024 15:57:09 +0200 (CEST) Received: (qmail 32565 invoked by uid 550); 13 Sep 2024 13:57:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32526 invoked from network); 13 Sep 2024 13:57:01 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nFSl1ELvKsuzQIfkFlmbYGu8ALYSnQGqeHCseDTAtwjmkwIdWEWc8QgaDqS0EoaJvgRPObasVR1+loatA01j5ypx5D4oGnrg97SXv8ks67cxKwJppvcvxYCA01tsKFlsz1nr7p10nLr8AO4l3MB53Fd/+GY/YUEPMZdGibhVskNdL/Jh1qVETQyU7DzWaBO1pIZlcfpDR5ACo9T16pfFqN7MjX3xCpMRVLfu7S0UH+/uehM3x5a/GN/C6XraFRNI+I6BMhtm0hz38DBdOW6uEhYMS7JSw3HeI2HE4rxzIlSP4PPKUaTu3HyurOgi/VGqdFrOdDXX97xnuodlyStODw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R9fUWbBRd2ATM2Ke5qAIrIjRlM7cMVR+5BWgrMYMWhQ=; b=okCY9k50Nomy6AoQuBk+BYLPpn8xjsghKRHCgzON1r0louJ7xGaJcHpDJ36St344Qo2GGYhX6EhwSfsrFfMXVIad6CSPbjfRmorU59iIG/MjR+vNNVFsVC0j6xa7MFmh4lknKGb1WfT5jFm/4nlWs3POmpdLdfkqbR2EPIlvivF/eItf83RMQ+bDvvqZE2r6ubkecjC6FEghYynTCUYL+JvFJpTDumcyo3/z8tJa3YX8rYNxMkW+iapWlg0jOPlXdTmgONUBzuie08nW4IPkGRj97IJy2+WIBLCFrDCYzKaDykz8gd9Eu6zPFiNlqHCg6POSGbORikyBhwHxIjbgKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R9fUWbBRd2ATM2Ke5qAIrIjRlM7cMVR+5BWgrMYMWhQ=; b=Ymscg8uVKn7RFlsCuFU1G3ej8FA2/Qq+2MCNGBY3cE8lIvI0lFj4SYVg9YQ5iUWre7GiyOx2NzaEnAcblRasF5pCpLRDYBSAGwYtn4CSAIEuiiXBlTsCwblnpKJnPXMSCoZ9BQzu4Z57axyPr/j4anWowRXSEf7tJ0l/53b/ks/JJshpJ1FXnArpFLuahInUiJtdLWzdoTE1dZPZQMyX6lMSXVYyw+hPJ7sDgl87w4MMEogSS4rPVhSuLyVfPLwMsjIxc9spcyvHJ02k7s7yzLR9HPCtMbSMJvIhRRF7yYRMBHSmNsT3C87ybrlXYTCyGSFUoplZf/9YFslPTAAylA== From: JinCheng Li To: musl Thread-Topic: Question about tcp failure in udp truncated scenarios Thread-Index: AQHbBdwvYNnopI2C6ESyVJHr1oaM/g== Date: Fri, 13 Sep 2024 13:56:49 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SE1P216MB2484:EE_|PU4P216MB2026:EE_ x-ms-office365-filtering-correlation-id: 4ae38117-ef50-4a3c-d722-08dcd3fbe9dc x-microsoft-antispam: BCL:0;ARA:14566002|15080799006|36102599003|8060799006|461199028|19110799003|15030799003|102099032|440099028|3412199025; x-microsoft-antispam-message-info: qr38ok+kB/3d1eHipcpussY7QZFXBOcF2l3tuVj69RjiVa7u9zE66VQCgTFlE0RxUWzhyfKY7ZcWiRgFZTCHJIovTVHsxfwJEgWwmqw2WMhNSSplHM8ngdo43oS6zNPZgJuP0NW22Gh8Z3jrloma91bA6Ad7vp98V50GugNXyGk938KG3RjXJNDp9k4ZujgpuzsDz4WY7MHICKn9bUvOQHkRWcQdxkqfeSYDwJXI2G9DdN9u40ntRHAztNa9H8PUohnAiqN4jfJ7OkTLnknGW87TAv6ObfPBsMkCYEdpe03arDemPVjg2lsAgqr4RN5k2AXVWJZnGE8nQByZEvh4uoIiJZB/nyrVdFsbf9ocSM1YnPeBs6a7bzfAqpFYmGhV60P/NtgHtjWu83vxBrO5DowxHmndo6D/CxZgeT7MMFOLDvIAkYwnY8s2s9LDRb/PZixfsmO1QuAfF1r0ZZgI2nCfuMKmJn2X9wNKETfOI4NzxNXbSiHgFe2yWHsiRKIJF5SO+N68fZ/QbKL8dqjgbcQ7tl8vOp3E67py8qlE7rQpJ7LZ0+/lxpzTkm+rR9gYdsNH/Ii2HIkNQXDj14GgtLfl+ZCDsXyeEhjpBPmQzNjF4VzlyLfLKZbbNJh0ZXySe2m6an/BhAwCzhiZw0iRaawANCjDFPUQ7gf2GHqzdhv/4FXzfdGi5jiqUu2m1pvm2l9b5lHKMhVe4rSNWBc+AAbKS3XHbPmBg8ET6V3SwfY12R5dLjnLRnVFjfMDCRju x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?UZLpAeSG1S/+A0JSgJun8voT4c65uYNL/VgksCxi5y3WnNx6k3pltlrj7I?= =?iso-8859-1?Q?dssEDuWKeupgR79oPh04idtCNQO4n0J94CfGfYVdEofX0l7kEZQPtB9FpF?= =?iso-8859-1?Q?mkcOqBO2ieOdMAS5C5zZFvZgeNpWC17blL1R1HzEutGO8X/s5jfC1MKA37?= =?iso-8859-1?Q?/iGvDPxX8mYnXeS2SYcr5w4Rzvws0YRT43FZSitgTQP4vtxRwCldSkQo64?= =?iso-8859-1?Q?NJGV1d1/2/8XOFSDpPrdSsXSARfWGY1tMbnePPp+53mxCRK95LT+OZM9g0?= =?iso-8859-1?Q?BHVNmjkKGrYXl8gPXJ4/wUvG+XttXDtLzDzQoX42SSTvUCPilWncpHyfA5?= =?iso-8859-1?Q?4/HgjvwRXPmAmY55S2O0H0ZCgOpv8mcaj+JbrpCR3bi/0y+ALB+qE+iCrd?= =?iso-8859-1?Q?ldgi619e5V0ph4YgSi1c4tcxJWfGFvmgvjqrb5qt8pKmaKiKV6P1UhwNcp?= =?iso-8859-1?Q?1XTgp0zGPuX2fZoTbSY45kYmU7EcowTj+5W3a1xXU2DpvzayA34l9J78y3?= =?iso-8859-1?Q?IBfuikVO6hoSggfZHN/rWOnWMLrr/EIvsbRZ8ucxn8g04ANU/qZ7sGilnr?= =?iso-8859-1?Q?7SqGNeVZiX8E4EYEt1zXojf2HqHDVEzuzOrTV6VDDeM/iuMNnYMMWb9bSS?= =?iso-8859-1?Q?BOE7fIYmgjP7FWYHbN56oXDfOQqAJQnVBWTJb5sMououUJc1yXs4pjx0mM?= =?iso-8859-1?Q?ioSB8S7A/7aX6uzN4b+1usfYeIIFDrkVzqR4tk9j3plZfVWayC7HsWTOqT?= =?iso-8859-1?Q?5ysHzSiCjLzbDpcFXwaMLaP32BmKWl2LacW6xcpIvnKIgw48pPShoAg4d6?= =?iso-8859-1?Q?C2f6b4Gv2Oz/MZScdkb6eBFgJApq1QCdtWEvJDwob1QwU3DNrVSAH4AKfa?= =?iso-8859-1?Q?kIgIVON8P+cIWG4m6LrEtdD7P/EdNWIfXoT4vJNwvjpCWFrs+MUPVimVEs?= =?iso-8859-1?Q?IxJPGChYMO98nmrMnmeXZDLdsPpBswHCGJ9h3QhOX+WRofPS0x6OBqllPa?= =?iso-8859-1?Q?JxKkVmvn2DBaUkVCM1PEqaUxu/IU9NJcMC6FTWnCkfJiQ29L3iPz9sCkGe?= =?iso-8859-1?Q?jnCrEzbyy0H8/FMLD8PPtWAiEOPD9vwgzPbTjtP0xvOlTfOFLvvxajflMs?= =?iso-8859-1?Q?0UAwQNgBsCFx8GYpsO7XdfwCuxVsSi3qtI9euLLP34DlL/RTE8fMEu3I+/?= =?iso-8859-1?Q?OWuFNYwZZcSCF06W2NbTKYUsEYapze28VJEbACXvur7A9KOu2loa/CCe1r?= =?iso-8859-1?Q?1NvsoQ5NsknjpbVF7FkSzy+uQTT+ISXAJVT04A+P4=3D?= Content-Type: multipart/alternative; boundary="_000_SE1P216MB248429552230F8F04DB93F8F9E652SE1P216MB2484KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SE1P216MB2484.KORP216.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 4ae38117-ef50-4a3c-d722-08dcd3fbe9dc X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2024 13:56:49.3393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU4P216MB2026 Subject: [musl] Question about tcp failure in udp truncated scenarios --_000_SE1P216MB248429552230F8F04DB93F8F9E652SE1P216MB2484KORP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have a question for __res_msend_rc in dns query. In the case of multi= ple nameservers, if the first vaild udp query result is truncated, musl wi= ll discard the udp query result and turn to tcp query. But I found many dns= nameservers do not response to the tcp connection or do not respond to tcp= query request which will finally trigger timeout. As a result, the success= rate of DNS queries is greatly reduced when udp is truncated, for example,= in the case of only IPV4. In bionic, the dns query in multiple nameservers is one by one. The fir= st udp is truncated, if the tcp also fail, it will turn to the second udp a= nd do it again. This may be slower than musl in terms of speed, but is more= stable in truncation cases. In musl, if the udp truncated case has happened, we will convert to tcp= which is more likely not supported by the nameserver and discard all other= udp response which may be also valid from other nameserver . Do you have a= ny good suggestions to optimize this? Best Li --_000_SE1P216MB248429552230F8F04DB93F8F9E652SE1P216MB2484KORP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi

    I have a question for __res_msend_rc in dns query. In the cas= e of multiple nameservers, if the first vaild udp query result is truncated= ,  musl will discard the udp query result and turn to tcp query. But I= found many dns nameservers do not response to the tcp connection or do not respond to tcp query request which will = finally trigger timeout. As a result, the success rate of DNS queries is gr= eatly reduced when udp is truncated, for example, in the case of only IPV4.=
    In bionic, the dns query in multiple nameservers is one = by one. The first udp is truncated, if the tcp also fail, it will turn to t= he second udp and do it again. This may be slower than musl in terms of spe= ed, but is more stable in truncation cases.
    In musl, if the udp truncated case has happened, we will conv= ert to tcp which is more likely not supported by the nameserver and discard= all other udp response which may be also valid from other nameserver . Do = you have any good suggestions to optimize this?

Best
Li
--_000_SE1P216MB248429552230F8F04DB93F8F9E652SE1P216MB2484KORP_--