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: DNS cache
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Babacar Ndiaye via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 4 Aug 2023 11:03:10 -0400
Thank you for the explanation.
On Thu, Aug 3, 2023 at 4:56 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Thu, 3 Aug 2023, Babacar Ndiaye via curl-library wrote:
>
> > "Typically this means asking for both IPv4 and IPv6 addresses and there
> may
> > be a whole set of those returned to libcurl. That set of addresses is
> then
> > tried until one works, or it returns failure."
> >
> > Does this mean the cache will on remember one single address (the first
> one
> > that worked)?
>
> No. The next time the address is used from the cache, the addresses are
> tested
> in the exact same order as it did the last time: in the order they were
> returned by the name resolver function.
>
> Trying the working version first (and the failing ones last) is certainly
> an
> optmization waiting to be done.
>
> > 2. Say we cache an entry and the name gets re-pointed to a new IP
> (service
> > moved to a new IP). Is your expectation that we'd get a code 7 (couldnt
> > connect to server) next time we try to reuse the IP?
>
> The expectation is primarily to only cache addresses for a period of time
> during which it is likely to still work. That's why the the default DNS
> cache
> timeout is set to only 60 seconds.
>
> If the host name changes address while the cache still holds the old set,
> there are several different potential outcomes when that is used.
> Including:
>
> 1. another service might use that address (and port) now, and if that is
> an
> unauthenticated protocol you might connect and issue requests to the wrong
> host. It might even succeed but give you unexpected data.
>
> 2. the service might use TLS and then you get a cert error
>
> 3. nothing might be answering on that IP/port so you get a connect failure
>
> 4. now something might swallow every packet on that IP so you get a
> connect
> timeout
>
> ...
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
>
Date: Fri, 4 Aug 2023 11:03:10 -0400
Thank you for the explanation.
On Thu, Aug 3, 2023 at 4:56 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Thu, 3 Aug 2023, Babacar Ndiaye via curl-library wrote:
>
> > "Typically this means asking for both IPv4 and IPv6 addresses and there
> may
> > be a whole set of those returned to libcurl. That set of addresses is
> then
> > tried until one works, or it returns failure."
> >
> > Does this mean the cache will on remember one single address (the first
> one
> > that worked)?
>
> No. The next time the address is used from the cache, the addresses are
> tested
> in the exact same order as it did the last time: in the order they were
> returned by the name resolver function.
>
> Trying the working version first (and the failing ones last) is certainly
> an
> optmization waiting to be done.
>
> > 2. Say we cache an entry and the name gets re-pointed to a new IP
> (service
> > moved to a new IP). Is your expectation that we'd get a code 7 (couldnt
> > connect to server) next time we try to reuse the IP?
>
> The expectation is primarily to only cache addresses for a period of time
> during which it is likely to still work. That's why the the default DNS
> cache
> timeout is set to only 60 seconds.
>
> If the host name changes address while the cache still holds the old set,
> there are several different potential outcomes when that is used.
> Including:
>
> 1. another service might use that address (and port) now, and if that is
> an
> unauthenticated protocol you might connect and issue requests to the wrong
> host. It might even succeed but give you unexpected data.
>
> 2. the service might use TLS and then you get a cert error
>
> 3. nothing might be answering on that IP/port so you get a connect failure
>
> 4. now something might swallow every packet on that IP so you get a
> connect
> timeout
>
> ...
>
> --
>
> / 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/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-08-04