Re: [musl] gethostbyname2_r returns invalid IPv6 address if DNS server replies IPv4 address

[Tom Shen <sjiagc.dev@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5535 bytes --]

> 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.

> 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?

Tom Shen

On Wed, Oct 19, 2022, 22:24 Rich Felker <dalias@libc.org> wrote:

> 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
>

[-- Attachment #2: Type: text/html, Size: 7033 bytes --]