Last bad IPv6 query response can make c-ares to report resolution failure even if there is previously successful IPv4 response
Dmitry Karpov
dkarpov at roku.com
Thu Apr 21 21:49:52 CEST 2022
Hi,
I recently stepped on an issue with curl using c-ares ares_getaddrinfo() with PF_UNSPEC family, when AAAA response from DNS server contained some bad data resulting into ARES_EBADRESP status code whereas A response was good.
The problem was that when AAAA response was the last received, it made c-ares to ignore previously received good A response and fail the host resolution with ARES_EBADRESP status code.
But if A response was the last received, then c-ares ignored the bad AAAA response and the host resolution was successful.
I looked at the c-ares code, and found the problem in the host_callback() function (src\lib\ares_getaddrinfo.c: 528)
static void host_callback(void *arg, int status, int timeouts,
unsigned char *abuf, int alen)
{
struct host_query *hquery = (struct host_query*)arg;
int addinfostatus = ARES_SUCCESS;
hquery->timeouts += timeouts;
hquery->remaining--;
if (status == ARES_SUCCESS)
{
addinfostatus = ares__parse_into_addrinfo(abuf, alen, 1, hquery->port, hquery->ai);
}
if (!hquery->remaining)
{
if (addinfostatus != ARES_SUCCESS && addinfostatus != ARES_ENODATA)
{
/* error in parsing result e.g. no memory */
end_hquery(hquery, addinfostatus);
}
else if (hquery->ai->nodes)
…
When there are no remaining queries, the ARES_EBADRESP parsing error is reported immediately, even though the previous query might be successful.
I suggest the following fix for this problem:
if (!hquery->remaining)
{
if (addinfostatus != ARES_SUCCESS && addinfostatus != ARES_ENODATA)
{
/* error in parsing result e.g. no memory */
if (addinfostatus == ARES_EBADRESP && hquery->ai->nodes)
{
/* We got a bad response from the server, but at least one query
* ended with ARES_SUCCESS */
end_hquery(hquery, ARES_SUCCESS);
}
else
{
end_hquery(hquery, addinfostatus);
}
}
I am also attaching a patch file with the potential fix.
Thanks,
Dmitry Karpov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.haxx.se/pipermail/c-ares/attachments/20220421/f1a37745/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c-ares-1.18.1-last-bad-server-response-fix.patch
Type: application/octet-stream
Size: 1265 bytes
Desc: c-ares-1.18.1-last-bad-server-response-fix.patch
URL: <http://lists.haxx.se/pipermail/c-ares/attachments/20220421/f1a37745/attachment.obj>
More information about the c-ares
mailing list