Date: Wed, 19 Oct 2022 10:24:54 -0400 From: Rich Felker <dalias@...c.org> To: Tom Shen <sjiagc.dev@...il.com> Cc: musl@...ts.openwall.com Subject: Re: gethostbyname2_r returns invalid IPv6 address if DNS server replies IPv4 address On Wed, Oct 19, 2022 at 11:44:45AM +0800, Tom Shen wrote: > Thanks for replying! > > > gethostbyname2 is legacy and has lots of inherent problems, so this > > really should be changed to use getaddrinfo. If nothing else, such a > > change would make it finish twice as fast. > > Ya, it is obsolete as stated in Linux doc. But a third-party service is > using "getent hosts" which calls this API. 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. > > Are you saying that the configured nameserver (coredns) is responding > > with an answer packet for a different question (A instead of AAAA) > > than the query packet asked for? I'm confused why it would do that. > > > It sounds like this is also wrong behavior by coredns. If it's > > rewriting AAAA queries to A for the sake of determining if the name > > exists vs NxDomain, that's fine for the outgoing query it performs, > > but instead of returning the answer to the rewritten query back to the > > asker as an answer that mismatches the question, it should just be > > removing the answer section to make it into a NODATA answer (if it's > > not already NxDomain). > > Yes. In CoreDNS, we can configure it to rewrite the request type AAAA to A, > so that the response will be IPv4 family and address. This is a CoreDNS > feature. I cannot find anything in the DNS standards against it so far. 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. > > The expected behavior of a process receiving such an answer would be > > to ignore it as bogus, but maybe we're not doing that, and then > > wrongly returning answers that don't match the type we asked for? > > Unfortunately, we return invalid IPv6 address as stated in the previous > email. But, maybe it's not good to mention it here, glibc can handle this > situation. > > > I'd rather fix this at the layer the actual bug (missing validation) > > is at. > > So, let me try to suggest a fix in __lookup_name or musl team would help to > take a look? So far I cannot find a way to create a pull request to musl > project. You can send patches to the list in plain diff or git format-patch form. Attachments are preferred over inline but inline is okay too if you're sure your mailer won't mess them up. But I have a proposed fix here. The last hunk needs to be applied manually since it has context affected by other DNS work I'm about to push (reversal of the for loop direction). Rich View attachment "badrrtypefix.diff" of type "text/plain" (1947 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.