New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
curl v7.66 onwards does not apply --resolve for the --doh-url #6589
Comments
bisected to b889408
I tried it as --libcurl output but I could not reproduce until I found this: Lines 1250 to 1253 in 2f33be8
Lines 2603 to 2607 in 2f33be8
If I comment out CURL_LOCK_DATA_CONNECT then I no longer see the double connection 0. If I comment out CURL_LOCK_DATA_DNS (regardless of if CURL_LOCK_DATA_CONNECT ) it uses the resolve, so I suspect something to do with sharing the DNS cache. I can reproduce with --libcurl output once I add this: CURLSH *share = curl_share_init();
curl_share_setopt(share, CURLSHOPT_SHARE, CURL_LOCK_DATA_DNS);
curl_easy_setopt(hnd, CURLOPT_SHARE, share); |
What's happening is the doh easy handles do not use the share from the user's easy handle. There are two hostcaches, the multi hostcache (ie the default hostcache if the user did not specify one, this is used by doh easy handles) and the user's share hostcache (which contains the fake resolve, this is used only by the user's easy handle). If I change doh to use the share from the user's easy handle then it works but I don't think it can be done safely since I'd guess it's possible that the user can destroy the share while the two doh handles are still in the multi and using it. diff --git a/lib/doh.c b/lib/doh.c
index 004244c..1c572d1 100644
--- a/lib/doh.c
+++ b/lib/doh.c
@@ -354,6 +354,7 @@ static CURLcode dohprobe(struct Curl_easy *data,
ERROR_CHECK_SETOPT(CURLOPT_SSL_EC_CURVES,
data->set.str[STRING_SSL_EC_CURVES]);
}
+ ERROR_CHECK_SETOPT(CURLOPT_SHARE, data->share);
doh->set.fmultidone = doh_done;
doh->set.dohfor = data; /* identify for which transfer this is done */ |
I don't think that should be possible (if it is, that's a bug). Those two transfers are "sub-handles" that should get removed and killed if the "main" easy handle that created them is done/removed/killed. I think the change you suggest here @jay is a sensible one and is in line with what users would expect libcurl to do. Make a PR out of it! |
- Share the shared object from the user's easy handle with the DOH handles. Prior to this change if the user had set a shared object with shared cached DNS (CURL_LOCK_DATA_DNS) for their easy handle then that wasn't used by any associated DOH handles, since they used the multi's default hostcache. This change means all the handles now use the same hostcache, which is either the shared hostcache from the user created shared object if it exists or if not then the multi's default hostcache. Fixes curl#6589 Closes #xxxx
I have been trying to test a DNS-over-HTTPS implementation and ran into issues with the curl command line not applying the
--resolve
option for the--doh-url
itself.Seems like this broke in curl v7.66. It's difficult to show a fully working example because of TLS, but see below for the DNS resolution of
--doh-url
.Expected Output (curl
v7.65
)doh.example.com
successfully resolved to1.1.1.1
Incorrect Output (curl
v7.66
)doh.example.com
is not resolved.The text was updated successfully, but these errors were encountered: