[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Jan 2023 14:58:47 +0000
From: Barry Bond <barrybo@...rosoft.com>
To: Rich Felker <dalias@...c.org>
CC: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: RE: [EXTERNAL] Re: Behavior change in getaddrbyname() with
AF_UNSPEC
OK, let me get more data about exactly what happened to the second query.
Barry
-----Original Message-----
From: Rich Felker <dalias@...c.org>
Sent: Wednesday, January 18, 2023 7:27 AM
To: Barry Bond <barrybo@...rosoft.com>
Cc: musl@...ts.openwall.com
Subject: [EXTERNAL] Re: [musl] Behavior change in getaddrbyname() with AF_UNSPEC
[You don't often get email from dalias@...c.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
On Sat, Jan 14, 2023 at 10:56:28PM +0000, Barry Bond wrote:
> This is related to this change: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.musl-libc.org%2Fcgit%2Fmusl%2Fcommit%2F%3Fid%3D5cf1ac2443ad0dba263559a3fe043d929e0e5c4c&data=05%7C01%7Cbarrybo%40microsoft.com%7C02af54c5fcbb4559460b08daf9686c4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638096524143833435%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Yh3xEyuJixzQbjEWRofxh85c%2BF6yxkUsxy3LgS2tasw%3D&reserved=0 made back in 2020.
>
> In the repro case, getaddrbyname() with AF_UNSPEC sends out two
> requests, but only gets back a single response, with the ipv4 address.
> There is no ipv6 on the network.
>
> name_from_dns() contains the relevant code. After __res_msend_rc()
> returns, 'nq' is 2, and 'alens' is [96, 0], indicating that there was
> an ipv4 response of 96 bytes, but no response for ipv6. Then the
> validation code runs:
>
> for (i=0; i<nq; i++) {
> if (alens[i] < 4 || (abuf[i][3] & 15) == 2) return EAI_AGAIN;
> if ((abuf[i][3] & 15) == 3) return 0;
> if ((abuf[i][3] & 15) != 0) return EAI_FAIL;
> }
>
> and the result is EAI_AGAIN, because alens[1]==0.
>
> Before this patch, the code would have parsed the ipv4 response via
> __dns_parse(), failed to parse the empty second response because
> alens[1]<12, and the function would return with ctx.cnt==1.
That was the wrong behavior that this patch fixed. Previously, the query was timing out, but because there was an answer to the other query, we were erroneously hiding the failure from the application and presenting a timing-/network-congestion-dependent incorrect result (wrongly claiming only A or only AAAA exist when in fact we didn't get enough information to make that determination).
"There is no ipv6 on the network" is not cause for the AAAA query to timeout. The ability to lookup a particular RR type has nothing to do with what network protocols are supported on your network. Can you describe the environment this is happening in and why it might be happening?
Rich
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.
