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: [EXTERNAL] HTTPS records
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Niall O'Reilly via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 01 Feb 2023 11:23:31 +0000
Due to adverse personal circumstances, I've not been able to follow up before now.
Please excuse my delay.
On 12 Dec 2022, at 10:42, Daniel Stenberg wrote:
> On Mon, 12 Dec 2022, Niall O'Reilly wrote:
>
>>> And getaddrinfo() does not return TTL.
>>
>> Arguably since RFC1034 (1987) and clearly since RFC8767 (2020), this seems to make addresses obtained from the DNS by getaddrinfo() unsuitable for cacheing.
>
> I disagree.
> Completely switching off caching would make repeated requests significanly slower in several scenarios.
I wonder about this. I'm seeing relative latency two or three orders of
magnitude less for repeated requests than for the initial (cold-cache) request.
I've tried this using a variety of local and public caching resolvers, including
unbound at ::1, kresd on my gateway router, and the services offered at 1.1.1.1
and 8.8.8.8, while using dig or hand-crafted code (invoking gettimeofday() before
and after getaddrinfo()) as the client.
I haven't put any effort into constructing pathological cases. I'm happy
to show my work, but don't wish at this stage to snow the mailing list with
mind-numbing detail.
Although it is absolutely reasonable to trade strict compliance with
standards for accommodation of certain scenarios, any decision on
resolving this tradeoff is opaque unless these scenarios are enumerated
and their prevalence experimentally estimated; this, no more than roughly,
as comprehensive enumeration or estimation of prevalence would be about
as useful as boiling the sea.
I suggest that it is worth considering also whether this tradeoff is
better decided once for every scenario and fixed in the libcurl code,
or rather left to those deploying curl in their respective scenarios,
by means of build- or run- time options.
> I would perhaps rather say that because we do not get *any* reports about problems with the existing caching, it might imply that it actually works fairly well. In spite of things.
I don't have enough information to reconcile this claim with what Dmitry
Karpov reported on 7 December (https://curl.se/mail/lib-2022-12/0024.html).
Best regards,
Niall O'Reilly
Date: Wed, 01 Feb 2023 11:23:31 +0000
Due to adverse personal circumstances, I've not been able to follow up before now.
Please excuse my delay.
On 12 Dec 2022, at 10:42, Daniel Stenberg wrote:
> On Mon, 12 Dec 2022, Niall O'Reilly wrote:
>
>>> And getaddrinfo() does not return TTL.
>>
>> Arguably since RFC1034 (1987) and clearly since RFC8767 (2020), this seems to make addresses obtained from the DNS by getaddrinfo() unsuitable for cacheing.
>
> I disagree.
> Completely switching off caching would make repeated requests significanly slower in several scenarios.
I wonder about this. I'm seeing relative latency two or three orders of
magnitude less for repeated requests than for the initial (cold-cache) request.
I've tried this using a variety of local and public caching resolvers, including
unbound at ::1, kresd on my gateway router, and the services offered at 1.1.1.1
and 8.8.8.8, while using dig or hand-crafted code (invoking gettimeofday() before
and after getaddrinfo()) as the client.
I haven't put any effort into constructing pathological cases. I'm happy
to show my work, but don't wish at this stage to snow the mailing list with
mind-numbing detail.
Although it is absolutely reasonable to trade strict compliance with
standards for accommodation of certain scenarios, any decision on
resolving this tradeoff is opaque unless these scenarios are enumerated
and their prevalence experimentally estimated; this, no more than roughly,
as comprehensive enumeration or estimation of prevalence would be about
as useful as boiling the sea.
I suggest that it is worth considering also whether this tradeoff is
better decided once for every scenario and fixed in the libcurl code,
or rather left to those deploying curl in their respective scenarios,
by means of build- or run- time options.
> I would perhaps rather say that because we do not get *any* reports about problems with the existing caching, it might imply that it actually works fairly well. In spite of things.
I don't have enough information to reconcile this claim with what Dmitry
Karpov reported on 7 December (https://curl.se/mail/lib-2022-12/0024.html).
Best regards,
Niall O'Reilly
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-02-01