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 29059 invoked from network); 4 Jul 2023 04:19:42 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Jul 2023 04:19:42 -0000 Received: (qmail 32601 invoked by uid 550); 4 Jul 2023 04:19:40 -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 32569 invoked from network); 4 Jul 2023 04:19:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688444367; x=1691036367; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=cgsUF76h2IsCl6ZAFYf6I27N+/zggmI32GbxTGXfuU8=; b=pFagviUFSM7vfk3xKilWW9BHiQq3uzK875VU5mlwdlImLGnjMiYFl5eNZspV8ZIk8P 84wSTUv04CAvzPJBW9uBMhu9wPoKtBiPWDA9/DeD8OqC+lIa3qb8Wx27vW5NKJEDqFsT anoefoi6tFakmvT+9wG2G6Xtyr2ka2Vm6hbGKFzecy+SUjIF2Nn3+VBsA4Mlfg4zvKBt 807Y17xzfSY1I+UGQ50t3u8wkMljD6BfaiBLU0UWMzhoR0jbwFCWkD/s9vDms9mM520g NUtP2uBA5FdKaUydefVe1GH8wGmaK88qWO/WIewDESaH8bRmwNzEX+i0q8e8ZocE6woz kf+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688444367; x=1691036367; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cgsUF76h2IsCl6ZAFYf6I27N+/zggmI32GbxTGXfuU8=; b=dZ6knToa969R6eOiOXpD+j90HQf+S/MPXEr+06xkHQBAH7DAX7yZMs8xev2QHZ4D4y cPPhZK8cU9tFl7cX3Ew3JCHrqRr7cE6S3LpgbDwy7+KjW+cn6mBuOzrw2QrW6dvV8e+v jjM3uoIvxTQZ1Q/gb8cd1LE3pkmihYdqtbVhK3vTDdEOJL/O+oXHt9fLoZ1ujPYAGkBf R7yR8Q6+KLGh+Wn4mz5a/iWQs0oPXHj+SyqYslpXgs/r/yk7BmLMj3v/579jZXii9Bou 274/wVqH1RK0Xstawmc2Vbn9hoTUkz6SnWcPOxnqNIzJvrYHSI5sIzwzhOg/7osUwU0H 36wQ== X-Gm-Message-State: ABy/qLa5j15cQBtyvDYq1UKQA5OJ3m6/TXuJiI8GU5YN2rdgsv1E5IiE Kutb07VI8Qy1NM5+Aw3XLr0JV5YxjHWdDM1npy/g49Ta X-Google-Smtp-Source: APBJJlHz+6C2qxb6jGudzy9OI1C41BuFAlQTNPCAe4/v+pAoCl4GqJdWcA94hG1DlUIn0sWovNuKnJgVj8g1RCr7yBw= X-Received: by 2002:a0c:f94a:0:b0:636:4f74:6e46 with SMTP id i10-20020a0cf94a000000b006364f746e46mr11714714qvo.56.1688444367218; Mon, 03 Jul 2023 21:19:27 -0700 (PDT) MIME-Version: 1.0 References: <20230704032918.GB4163@brightrain.aerifal.cx> In-Reply-To: From: Hamish Forbes Date: Tue, 4 Jul 2023 16:19:16 +1200 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: RE: [musl] DNS answer buffer is too small On Tue, 4 Jul 2023 at 15:29, Rich Felker wrote: > Your report here is missing the motivation for why you might care to > have more than 768 bytes of response, which, as I understand it, is > because of CNAME chains. Yes, sorry, a response can contain a chain of CNAMEs like a.example.com 10 IN CNAME b.example.com. b.example.com 10 IN CNAME c.example.com. ... n.example.com 10 IN A 127.0.0.1. With a max length per CNAME of 255 this could quickly blow out the 768 byte limit. > Otherwise, the buffer size is chosen to hold > the number of answer records the stub resolver is willing to accept, > and there is no problem. Are you referring to the 48 MAXADDRS limit? That's also possibly a problem in edge cases though, isn't it? AIUI that was chosen as the maximum number of IP responses that can fit in a 512 byte UDP response. With TCP DNS implemented now, is that still a safe assumption? It seems nuts to be returning more than 48 addresses but the DNS spec doesn't prevent it, so I bet it's being done somewhere! This post[0] I came across while investigating all this stuff is somewhat related > Long CNAME chains are rather hostile and are not guaranteed to be well > supported -- AIUI recursive nameservers already impose their own > limits on the number of redirections in a chain, though I cannot find > any specification in the RFCs for this behavior or suggesting a value > for that limit, so if you can dig up what they actually do, this would > be useful to know. But it seems there are chains longer than what we > currently support out in the wild, which most software does support. > So the next step is nailing down exactly what the "requirement" here > is, so we can figure out what's the most reasonable and least costly > way to do it. Bind defaults[1] to 7, although that appears[2] to only be when it has to switch to another NS. So if the CNAME chain is all in the same zone... that's only a depth of 1 Looks like Unbound defaults[3] to 11. Although it also has a slightly confusing 'target-fetch-policy' which looks to limit depth in a similar way to Bind, maybe... > If there's some moderately small limit on the number of redirections > that recursive software supports, it may make sense to just increase > the buffer size to match that. If there really can be very large > chains, this is a mess. I have a strong suspicion that this is, in fact, going to be a mess :) > Rich [0] https://www.netmeister.org/blog/dns-size.html [1] https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-max-recursion-depth [2] https://groups.google.com/g/comp.protocols.dns.bind/c/1GoKujM2Ylw/m/l_DuNxWFiCUJ [3] https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-max-query-restarts