From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19455 invoked from network); 4 Jul 2023 00:17:33 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Jul 2023 00:17:33 -0000 Received: (qmail 13487 invoked by uid 550); 4 Jul 2023 00:17:29 -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 13455 invoked from network); 4 Jul 2023 00:17:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688429837; x=1691021837; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=qNXP1tBx6+3RaLH4dpvHeWQxNjj+H8Rw2A2s/HMVC/8=; b=BE65gABdcyHMmOk99vA37Bxz5rPpVavaIFaUHX9vFi8hnRCY4V34o2M2yF85zLSrPo 6M0HSZo69BAw2tjqPp0ZCA7ywv+4HZIEQ1Jaz+K+OyKG0iyZXS0HvqjdT0pwnatElCmH 0u+j/QC8d6TNlOp9CCA4dEDEfMQhiCnINp5CsbEU0VG5uBbw5BhvS+tgttzCZJe4mIER BPdW6F5f7WhAjL02t6WsTRQkYa+4VI9WeX63VGZscv/nC5d5MOuwcmeZ+0ArlmJYrMKE 9C6X5zTlzpnk1dSLBXhMyCcxnIy3OC6E2eo3/jmLtbDMCUTrYqj9PLQzt94B7VRRejSF 6Llg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688429837; x=1691021837; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=qNXP1tBx6+3RaLH4dpvHeWQxNjj+H8Rw2A2s/HMVC/8=; b=iX/zwJiJjCvD9HzLiI8p6OigeUG3PrfXh5ebBHyJsOa+UgPb4dOHi73y9r8m1cMmPr nCkPVwSkQFoeZ9HZrmq/QfZiN1gpRRk4N2q6ZOmWiOiVRwjKLG3pXs+l6R/AYqEFJ2pD AooPjL0kNYTbuqNJ668Zgo0wWO6tyK+xFN9IqB3wCvBJPXSfh4+cuynjuOCQTZc99YKr NHR6JSKks/ude7qNNkSOSEdSQK17+1Hmdgwm4LnmrSCiy9MZSyAi3VnldUJ61PbZbwoO HpPpMq8talxhvHzFUQLSFVH0oKLmxvf6VdjfTXjViXchLLZvIZLPyvkRb8aN8cqnMsyO kFDg== X-Gm-Message-State: AC+VfDyA4A+8kBVUFXy3NkDtGO6VAVnR9AZVDFDeQJh9W7A8uDYBHlPO /v5pEpHZ7BP1sKr8ybgNIUSou8NsnPAj6H7dYJ+bIITisyU= X-Google-Smtp-Source: ACHHUZ5u/fuA33mtt+HLcrlCjPoNwGvEjtwln4IUdpDMbrMQLrMIPrOMfFpjnzxhCHd2Ev+BQ+1yWk5YWap53St198k= X-Received: by 2002:a05:6808:291:b0:3a1:eb15:5ec4 with SMTP id z17-20020a056808029100b003a1eb155ec4mr9747512oic.42.1688429836632; Mon, 03 Jul 2023 17:17:16 -0700 (PDT) MIME-Version: 1.0 From: Hamish Forbes Date: Tue, 4 Jul 2023 12:17:05 +1200 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: [musl] DNS answer buffer is too small In lookup_name.c the DNS answer buffer (ABUF_SIZE) is currently hardcoded to 768 bytes, increased from 512 after TCP DNS was implemented. The DNS RFC is, unfortunately, not very explicit about the size of TCP responses. However it does have this little line: > RFC 1035 4.2.2. > The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. Which you could interpret as the TCP response length is a 16bit unsigned int, so 64K. But that's also the raw (potentially compressed) DNS response, the uncompressed response could be larger still. As best I can tell (I am not a C programmer!) glibc is using a scratch buffer which grows when the parsing function returns an ERANGE error. If that's more complex than you want, maybe a good compromise would be allocating 768 (or 512?) for UDP queries and expanding to 64k when a query falls back to TCP? Hamish