Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: IPv6 resolution problems for IPv4 resolve mode
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 12 Jul 2022 16:27:53 +0200 (CEST)
On Mon, 11 Jul 2022, Timothe Litt via curl-library wrote:
> The name IPRESOLVE_* implies that it controls resolution, but the
> description says it controls "what kind of IP addresses to use when
> establishing a (possibly cached) connection:.
Yes, the name could be better but I don't we need to argue about that detail.
The question is really what libcurl should do when the different values are
set.
> Complicating this is the DNS cache, which is shared across all curl handles.
> Evicting cache entries to control connections is counter-intuitive and
> inefficient. Consider the case of one handle wanting IPv4 for SSH to a host,
> but IPv6 for http...
That's exactly the case we had when we recently changed this code, which then
introduced the problems Dmitry is seeing...
> The cache should, subject to TTL, hold all resolutions ever performed for a
> name - v4, v6, or both. This includes caching the case of a resolution
> returning "Answers:0" (no address of that type).
The TTL is not generally accessible so the cache is not using that. There is
also no negative caching (ie a cache miss will cause another name resolve) -
but it has been mentioned as a TODO since basically forever.
> With respect to a default: it should be both. The fact that some issues
> still occur with IPv6 in some environments just means that those
> environments are broken. It's fine to have a work-around for them. But
> defaulting to the work-around only discourages these from being fixed. Like
> it or not, IPv6 is the going-forward plan for the network and adoption is
> happening, however slowly.
I think we all agree on this. Dmitry wants the/a work-around to avoid the IPv6
problem he's seeing.
> Again: the handle should specify how to connect. The cache should hold the
> result of lookups, which are triggered when needed. Don't conflate the two.
Since Dmitry's problem is in the resolve phase, the work-around for that issue
probably must change the resolving part and then as a direct follow-up effect
it affects what is cached for that name... I can't think of a away to avoid
that!
Date: Tue, 12 Jul 2022 16:27:53 +0200 (CEST)
On Mon, 11 Jul 2022, Timothe Litt via curl-library wrote:
> The name IPRESOLVE_* implies that it controls resolution, but the
> description says it controls "what kind of IP addresses to use when
> establishing a (possibly cached) connection:.
Yes, the name could be better but I don't we need to argue about that detail.
The question is really what libcurl should do when the different values are
set.
> Complicating this is the DNS cache, which is shared across all curl handles.
> Evicting cache entries to control connections is counter-intuitive and
> inefficient. Consider the case of one handle wanting IPv4 for SSH to a host,
> but IPv6 for http...
That's exactly the case we had when we recently changed this code, which then
introduced the problems Dmitry is seeing...
> The cache should, subject to TTL, hold all resolutions ever performed for a
> name - v4, v6, or both. This includes caching the case of a resolution
> returning "Answers:0" (no address of that type).
The TTL is not generally accessible so the cache is not using that. There is
also no negative caching (ie a cache miss will cause another name resolve) -
but it has been mentioned as a TODO since basically forever.
> With respect to a default: it should be both. The fact that some issues
> still occur with IPv6 in some environments just means that those
> environments are broken. It's fine to have a work-around for them. But
> defaulting to the work-around only discourages these from being fixed. Like
> it or not, IPv6 is the going-forward plan for the network and adoption is
> happening, however slowly.
I think we all agree on this. Dmitry wants the/a work-around to avoid the IPv6
problem he's seeing.
> Again: the handle should specify how to connect. The cache should hold the
> result of lookups, which are triggered when needed. Don't conflate the two.
Since Dmitry's problem is in the resolve phase, the work-around for that issue
probably must change the resolving part and then as a direct follow-up effect
it affects what is cached for that name... I can't think of a away to avoid
that!
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-07-12