Last bad IPv6 query response can make c-ares to report resolution failure even if there is previously successful IPv4 response

[Dmitry Karpov]

Thanks a lot, Brad!
I didn’t receive your reply somehow.

From: Brad House <brad at brad-house.com>
Sent: Monday, May 2, 2022 5:11 PM
To: c-ares discussions <c-ares at lists.haxx.se>
Cc: Dmitry Karpov <dkarpov at roku.com>
Subject: Re: Last bad IPv6 query response can make c-ares to report resolution failure even if there is previously successful IPv4 response

Appears to be a duplicate, a reply was sent out to the original:
https://lists.haxx.se/pipermail/c-ares/2022-April/000035.html
On 5/2/22 8:08 PM, Dmitry Karpov via c-ares wrote:
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/20220503/a519f5c9/attachment.htm>