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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14602 invoked from network); 20 Oct 2022 00:52:34 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Oct 2022 00:52:34 -0000 Received: (qmail 3919 invoked by uid 550); 20 Oct 2022 00:52:30 -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 3872 invoked from network); 20 Oct 2022 00:52:29 -0000 Date: Wed, 19 Oct 2022 20:52:14 -0400 From: Rich Felker To: Tom Shen Cc: musl@lists.openwall.com Message-ID: <20221020005214.GM29905@brightrain.aerifal.cx> References: <20221018172727.GK29905@brightrain.aerifal.cx> <20221019142452.GL29905@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] gethostbyname2_r returns invalid IPv6 address if DNS server replies IPv4 address On Thu, Oct 20, 2022 at 12:00:46AM +0800, Tom Shen wrote: > > Right. I'm saying the maintainers of this version of getent should be > > informed that they're using a backwards nonstandard function here and > > that it would work better with getaddrinfo. > > The getent Linux manual states that when using database hosts, > gethostbyname2 would be called. > https://man7.org/linux/man-pages/man1/getent.1.html . Maybe we can persuade > the third party service to use getent ahosts. Uhg, lovely that it's specified like that... But really, it only needs to behave "as if" it did that, which can be done better using getaddrinfo with the right options to get the behavior the legacy APIs would have given, but in a better way. So I think it's still worth pursuing this kind of improvement too. Orthogonal to your problem report, though. > > I inquired about this and got the response that there might not be an > > explicit rule against it, "much like no RFC prohibits you from eating > > glass". :-) I don't see how the behavior makes any sense though. There > > is a risk that strict stub resolvers could consider these packets > > non-answers and timeout/fail rather than returning a response, and > > like you found, a chance that buggy stub resolvers not doing > > sufficient validation could misinterpret the answers. I'm not clear > > where these wrong-type answers could give useful results, especially > > not anything more-useful than just returning NODATA in place of the v6 > > result you want to suppress. > > True. Maybe we should not use this "rewrite type AAAA A" feature in > CoreDNS. Just on Internet there are some posts suggested it to fix the name > resolution issues caused by unexpected IPv6 logic. We already removed it > from our system since an incident. I am not an expert in DNS though, so > cannot comment more about the standards. > > Anyway, although rewriting the DNS request type may make no sense, we > should either return correct IPv6 address (e.g. ::ffff:10.96.36.74) or IPv4 > address (10.96.36.74) or NODATA, rather than an invalid IPv6 address > (a60:244a::) :-). I got your point in last email, and I also have the same > idea, returning NODATA is a good (or only) solution. In getent hosts > command, when getting empty result for AF_INET6, it will call > gethostbyname2 with AF_INET (this is also the behavior of glibc's getent > https://codebrowser.dev/glibc/glibc/nss/getent.c.html), then we will get > correct IPv4 address. > > > But I have a proposed fix here. > > Thank you so much, Rich! Your change looks better than what I would do. I > will try it out. If tested good, would we merge the fix into later releases? Yes, I'm getting it merged now. Thanks for the report. In some sense this was a long-known issue (that "malicious" nameservers could give wrong-RR-type answers -- see CVE-2017-15650) and it's nice to finally have good reason to put in the attention to fixing it. Rich