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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15736 invoked from network); 19 Oct 2022 16:01:14 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Oct 2022 16:01:14 -0000 Received: (qmail 25735 invoked by uid 550); 19 Oct 2022 16:01:10 -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 25702 invoked from network); 19 Oct 2022 16:01:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bjzzoz+Viq6DcOtAxjjd79knmTEZk8KTQFfidwcu8/E=; b=SImMuavGYdIgMhXqU8HBO1tblXy3Lp4nxUldUWz8u/ePBcGuzQxFH61p97InfhEooC su+u97fqq+p0K6k2qJ3hT/nrKlLNkUXaes2L9HKGjiOlKsnMwOQEBeeq0znS8XEdJCJI Z9oReW9LVAdudMiSLR8x6M+x+KimQqnS8LCgN3LsntbgzEc0ILwGVGaXnNTMlc91T9tu fniEUvfrx9m8pJuLRpKImdBk0/rnPuvcJx+vET+feQHyEvqjnt/8OPbw/0vB0TWSGqxn GtKushmhwXD3lV62jF4YQ/OhHIpE/qmlufcz28Y8GjIif5yOaDju6MQKQvwZdmLwp2cR Un7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=bjzzoz+Viq6DcOtAxjjd79knmTEZk8KTQFfidwcu8/E=; b=ByNgeqwuAMrE7+ZJAwbOdtXe6wKdzL9QiRf2+KgqeHFUTwBwFU460YsQXiEhUs55om MVTllkutdzvC6mpI1kPsKP3YtIPuq1Ku2sXt9hXAsdPmP4rr3/6UBgWPqLeZ1oWnvpX6 N5RzreSipAhoSpn0u2oqZjX5X3QWi08AdATcOlqrcugiTK7a79S48lelqqSy2F6d/HLo yAgIK6GsZaoKK4VK7YO/M8VhSJ3UzEKO9wi6LEnCufVULRpurIO3QfhvGLDNm+ZkHTJp 0wP6EX+DgbDZTDFP+kxfMq8QyUjXsFXaxpQ7efhPeqRnIajjMtMiBFxkIU/rpKT0c0Sa Scow== X-Gm-Message-State: ACrzQf2ZtA1jgvDljfdW05cVbNs2l4MXRlF48Edh3ITYwfkKC3yOcHQ9 o6Yv8X8r4nf29a4EuhAzFjqzI2/F9Sq6Vo5eA2WGYnpY X-Google-Smtp-Source: AMsMyM7N5P0x9Re4IUhcBhNwJa3IowCb8lhK/mo4VM58onlbnOC0qJVD1Q/SW1khtBqCNcG13f+zv8SO0dc6LC5MxV8= X-Received: by 2002:a17:907:74e:b0:74f:83d4:cf58 with SMTP id xc14-20020a170907074e00b0074f83d4cf58mr7510370ejb.178.1666195258750; Wed, 19 Oct 2022 09:00:58 -0700 (PDT) MIME-Version: 1.0 References: <20221018172727.GK29905@brightrain.aerifal.cx> <20221019142452.GL29905@brightrain.aerifal.cx> In-Reply-To: <20221019142452.GL29905@brightrain.aerifal.cx> From: Tom Shen Date: Thu, 20 Oct 2022 00:00:46 +0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000863b6005eb655006" Subject: Re: [musl] gethostbyname2_r returns invalid IPv6 address if DNS server replies IPv4 address --000000000000863b6005eb655006 Content-Type: text/plain; charset="UTF-8" > 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 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 > --000000000000863b6005eb655006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Right. I'm saying the maintain= ers of this version of getent should be
> informe= d 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.=C2=A0 https://man7.org/l= inux/man-pages/man1/getent.1.html . Maybe we can persuade the third par= ty 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&quo= t;. :-) 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 rat= her than returning a response, and
> like you fou= nd, 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 t= han just returning NODATA in place of the v6
> re= sult you want to suppress.

True. Mayb= e 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 resolu= tion 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 comm= ent 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 IPv= 4 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, w= hen 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.
<= div dir=3D"auto">
> 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. I= f tested good, would we merge the fix into later releases?

Tom Shen<= /div>

On Wed, Oct 19, 2022, 22:24 Rich Felker <<= a href=3D"mailto:dalias@libc.org">dalias@libc.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">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 th= is
> > really should be changed to use getaddrinfo. If nothing else, suc= h a
> > change would make it finish twice as fast.
>
> Ya, it is obsolete as stated in Linux doc. But a third-party service i= s
> 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 respon= ding
> >=C2=A0 =C2=A0with an answer packet for a different question (A ins= tead of AAAA)
> >=C2=A0 =C2=A0than the query packet asked for? I'm confused why= it would do that.
>
> >=C2=A0 =C2=A0It sounds like this is also wrong behavior by coredns= . If it's
> >=C2=A0 =C2=A0rewriting AAAA queries to A for the sake of determini= ng if the name
> >=C2=A0 =C2=A0exists vs NxDomain, that's fine for the outgoing = query it performs,
> >=C2=A0 =C2=A0but instead of returning the answer to the rewritten = query back to the
> >=C2=A0 =C2=A0asker as an answer that mismatches the question, it s= hould just be
> >=C2=A0 =C2=A0removing the answer section to make it into a NODATA = answer (if it's
> >=C2=A0 =C2=A0not 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 CoreDN= S
> 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<= br> glass". :-) I don't see how the behavior makes any sense though. T= here
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.

> >=C2=A0 =C2=A0The expected behavior of a process receiving such an = answer would be
> >=C2=A0 =C2=A0to ignore it as bogus, but maybe we're not doing = that, and then
> >=C2=A0 =C2=A0wrongly returning answers that don't match the ty= pe we asked for?
>
> Unfortunately, we return invalid IPv6 address as stated in the previou= s
> email. But, maybe it's not good to mention it here, glibc can hand= le this
> situation.
>
> > I'd rather fix this at the layer the actual bug (missing vali= dation)
> > is at.
>
> So, let me try to suggest a fix in __lookup_name or musl team would he= lp to
> take a look? So far I cannot find a way to create a pull request to mu= sl
> 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 f= ix
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<= br> direction).

Rich
--000000000000863b6005eb655006--