Can you be more specific? Can you deduct what causes the issue and produce a full demo source code that reproduces the issue for you when you run it? That way we would a good way to debug this. Simply reverting that commit is too crude and will only bring back the bug it fixed.

Sure, I'll try to make a small demo. Sharing what I've done so far and looking for possible tips or clues.

So
curl_easy_setopt(curl_master, CURLOPT_DNS_SERVERS, "1.2.3.4,1.2.3.5");
new_handle = curl_easy_duphandle(curl_master);
curl_easy_perform(new_handle);

...doesn't work anymore, but:

new_handle = curl_easy_duphandle(curl_master);
curl_easy_setopt(curl_master, CURLOPT_DNS_SERVERS, "1.2.3.4,1.2.3.5");
curl_easy_perform(new_handle);

...still works.

Ok this was actually pretty easy to write a testcase for.

This is the output I expect:

LD_LIBRARY_PATH=/home/ernsjo/curltest/install-762/lib/ ./test 
hello libcurl/7.62.0-DEV OpenSSL/1.0.2n zlib/1.2.11 c-ares/1.14.0 libidn2/2.0.4
* Could not resolve: really.not.a.server (Could not contact DNS servers)
* Closing connection 0

However with 7.63+ I get:

LD_LIBRARY_PATH=/home/ernsjo/curltest/install/lib/ ./test 
hello libcurl/7.69.0-DEV OpenSSL/1.0.2n zlib/1.2.11 c-ares/1.14.0 libidn2/2.0.4
* Could not resolve: really.not.a.server (Domain name not found)
* Closing connection 0

Here it's forgotten all about my special DNS server.

test.c.txt

Oh I didn't realize there actually is a DNS server on 9.9.9.9, but the port is wrong at least. :-)
Bugs in test.c aside, we want the "Could not contact DNS servers" print.

Clearly, options in the CURLOPT_DNS_* family don't survive a call to curl_easy_duphandle() so when you use the duplicate you get the c-ares default DNS settings. Are you saying this actually did the right thing back in 7.63.0 ?

In 7.62.0 it did the right thing yes. In 7.63.0 and higher it does not work.

Are you sure this is actually the same problem then? Because libcurl never duplicated the CURLOPT_DNS_* options when you called curl_easy_duphandle() which is quite easy to verify by reading the code.

Well you can see that test.c prints "Could not contact DNS servers" with 7.62.

Ok so you're saying that I'm using the api in a wrong way then? I haven't been able to clearly find this in the documentation (which is otherwise very thorough).

This code:

  curl_master = curl_easy_init();
  curl_easy_setopt(curl_master, CURLOPT_URL, "https://curl.haxx.se/");
  curl_easy_setopt(curl_master, CURLOPT_DNS_SERVERS, "1.2.3.4,1.2.3.5");
  new_handle = curl_easy_duphandle(curl_master);
  ret = curl_easy_perform(new_handle);

Will simply use the default name server c-ares figures out, not the one set in the master handle.

Thus a simpler code that does the same thing is:

  curl_master = curl_easy_init();
  curl_easy_setopt(curl_master, CURLOPT_URL, "https://curl.haxx.se/");
  ret = curl_easy_perform(curl_master);

Will simply use the default name server c-ares figures out, not the one set in the master handle.

Not with 7.62, I clearly see that it uses the one from the master handle.

Ok, I read you. Will dig deeper and see what I'm missing...

I found the issue. You were of course right and I didn't dig deep enough until now.

In the commit that closed #3238, the code changed the the function Curl_resolver_duphandle() which previously used ares_dup() to duplicate the c-ares handle and then it would duplicate even the custom set DNS servers.

In the fix, the code changed that to instead do a fresh ares_init which of course then loses the custom DNS servers... The fix does this because apparently: "ares_dup does not allow passing a different sock_state_cb_data". Which of course is a c-ares bug (or missing feature perhaps) rather than anything else.

Now, for the best step to fix this I need to think a little...

I think this should be fixed by

1. adding the necessary API to c-ares so that we can use ares_dup() in there
2. until (1) is done, add a work-around in curl that stores the DNS server string in the easy handle and when duplicated, it can set them for the newly created cares channel.

What do you think @ernstp?

@bagder Sure, 2) sounds lightweight enough, and nice and generic.

@ernstp do you feel up for working on this?

@bagder Yeah it looks like I can give it a shot.

@bagder Should (2) be ifdefed so it only exists when you compile with cares? always do if for all backends?