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 13965 invoked from network); 5 Jul 2023 00:18:40 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Jul 2023 00:18:40 -0000 Received: (qmail 30647 invoked by uid 550); 5 Jul 2023 00:18:36 -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 30612 invoked from network); 5 Jul 2023 00:18:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688516303; x=1691108303; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bbQ+PXU9TUBnlICFujlFlXf8oLXBLHXSe2KUz7jtGZY=; b=Wt1UlYRw9BSI7T9WQVanh7ouPQrWWljhq6+O7lQ6AVZeNM9R+YF7JBEyUEiMrxnGHm AcZv9PyUx/2PkDMdlxN3XNKH0ZmVofoR3VD1JhagEYEMRyhVUJr0T1YMEQuyVZCSnKlJ UYfBUwOn/okqB9Ob9iwAdwwvCJbNcIY12f7QOsedZwiIE+bRodn2MMyT5Bqg6KAYnn7S CQHkF7IaW5bXtGjC1vCaPUATB8/pldUeCMAGpcrHGubwzNzU3lPXU1gIn1S8oaVjN5DL pKqqvYLphQf6LOfSN6zGPvIxuVFOd6qs7+nBujc8LSUBNF6cVON40aFeDJITbxSP4eju vGzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688516303; x=1691108303; h=cc: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=bbQ+PXU9TUBnlICFujlFlXf8oLXBLHXSe2KUz7jtGZY=; b=bqVxTrLd+hWYGDudqUsh9yJpGF/szXnXCMTRseM7LyHqoV/aHn3eIFvtArOuNFrkJM fY8t+BhLOQsrYsJ4HBKlnfhjIPKjN36UIIUp/flEpOisyOm6vy271KNJFp55iVgkO+tl 0OlsKuq3NFVkMtNVUtC08VfOtruPxhO4dCQchPqPdnai/mK1L8hzmYcZfbj9liLVBGjT 0vAPLXqkeUuQlMkEdcR2YI2E+gifNt/aR1LTEwLkvPhF02fKZwRyQcLw6uZxAw1RxGXc +Ni8chtInOA3fDAMHpYXD/dBWLxGxnADNGBWqdazQMR1cQKpTJfu1Z/1K2392NqMbgEr kmWw== X-Gm-Message-State: AC+VfDw5KlfxGghdQFdGUw7jIMsfgzN3uC0oui6Z/zBdBoqhqK1fOqI5 0TxJvupB3S7FRbYnP2YiezVckkcCgELfNVdDDOY= X-Google-Smtp-Source: ACHHUZ58+nE9P/39ZJunMqyEzrkadNbL/SN2121da0lbaIkIosu5b0xk8tkLSmhaudDXIQSXwZNqsLBGeqimOKJU6tM= X-Received: by 2002:a05:6a20:4c23:b0:126:81ef:f18d with SMTP id fm35-20020a056a204c2300b0012681eff18dmr14710756pzb.40.1688516302924; Tue, 04 Jul 2023 17:18:22 -0700 (PDT) MIME-Version: 1.0 References: <20230704032918.GB4163@brightrain.aerifal.cx> <20230704160700.GC4163@brightrain.aerifal.cx> In-Reply-To: <20230704160700.GC4163@brightrain.aerifal.cx> From: Hamish Forbes Date: Wed, 5 Jul 2023 12:18:11 +1200 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] DNS answer buffer is too small On Wed, 5 Jul 2023 at 04:06, Rich Felker wrote: > > On Tue, Jul 04, 2023 at 04:19:16PM +1200, Hamish Forbes wrote: > > On Tue, 4 Jul 2023 at 15:29, Rich Felker wrote: > It's as safe as it was before, and it's always been the intended > behavior. Aside from the CNAME chain issue which wasn't even realized > at the time, use of TCP for getaddrinfo is not about getting more > answers than fit in the UDP response size. It's about handling the > case where the recursive server returns a truncated response with zero > answer records instead of the max number that fit. It turned out this > could also occur with a single CNAME where both the queried name and > the CNAME target take up nearly the full 255 length. > > As for why not to care about more results, getaddrinfo does not > provide a precise view of DNS space. It takes a hostname and gives you > a set of addresses you can use to attempt to connect to that host (or > bind if that name is your own, etc.). There's very little utility in > timing out more than 47 times then continuing to try more addresses > rather than just failing. "Our name resolves to 100 addresses and you > have to try all of them to find the one that works" is not a viable > configuration. (A lot of software does not even iterate and try > fallbacks at all, but only attempts to use the first one, typically > round-robin rotated by the nameserver.) > > Anyway, if there are objections to this behavior, it's a completely > separate issue from handling long CNAME chains. Ah yeah, ok that makes sense. I wasn't thinking about it as "we just need any address". No objections to that from me! > From my reading of your links, and > > https://groups.google.com/g/comp.protocols.dns.bind/c/rXici9NvIqI > > I don't think max-recursion-depth is related to CNAMEs. It's the depth > of delegation recursion. The max CNAME chain length is separate, and > in unbound terminology is the number of "restarts". Unbound's limit as > you've found is 11. BIND's is supposedly hard-coded at 16. > > Assuming the recursive server uses pointers properly, max size of a > length-N CNAME chain is (N+1)*(255+epsilon). This comes out to a > little over 4k for the BIND limit, and that's assuming max-length > names with no further redundancy. I would expect the real-world need > is considerably lower than this, and that the Unbound default limit on > chain length also suffices in practice (or it wouldn't be the default > for a widely used recursive server). So, for example, using a 4k > buffer (adding a little over 3k to what we have now, which already had > enough for one CNAME) should solve the problem entirely. > > Does this sound like an okay fix to you? Sounds good to me! > > Rich