In part I, part II and part III I talked about the changes to DNS resolution in curl and why we do them. In this post I cover the performance/resources related changes in the threaded resolver. This is the most common build option, deployed by many distros.

Previously…

In curl 8.19.0 and earlier, the “threaded resolver” means libcurl starts a new thread to call getaddrinfo(), as I explained in part II. In addition, it opens a socketpair (or eventfd on modern linux), so the resolver thread can notify the “main” thread it’s done.

In part I and part II I talked about the changes to DNS resolution in curl and why we do them. In this post I cover the difference and changes in synchronous vs asynchronous resolution. Which matter for Happy Eyeballs v3 (HEv3) and Encrypted Client Hellos (ECH).

Sync/Async, Old and New

Out of all the DNS options I described in part II, the most compatible and most deployed one is getaddrinfo().

Sync, no threads or c-ares

In part I I talked about the changes to DNS resolution in curl and why we do them. In order to see where they apply and if/under which conditions you benefit, we need to shine some light on what “DNS resolution” in curl is.

Options

As you probably know, curl and libcurl is available on many platforms with capabilities that vary greatly. This also applies to DNS resolution. One configures at build time what mechanism to use. That might require additional libraries like c-ares. Not enough flexibility? You can also at runtime tell curl to use DNS-over-HTTPS (DoH).

We are making changes this year in how curl (or better libcurl) operates in regard to DNS resolution. The first of those will appear in curl 8.20.0 in April.

Why?

There are three reasons we overhaul how libcurl interacts with DNS:

1. “Encrypted Client Hello” (ECH)
2. “Happy Eyeballs v3” (HEv3)
3. Performance and Resource Use

ECH is an extension in the TLS handshake that hides the name of the server a client wants to talk to (the “SNI”) from someone looking at the IP packets. You can read a good, detailed explanation at this Feisty Duck newsletter. It provides privacy and anti-censorship. In an era where governments are increasingly hostile, seems a good thing to have.

The curl project merged #19384, #20033 and #20228 which re-implements rate limiting of transfers in libcurl. This will be part of the upcoming 8.19.0 release at the beginning of March 2026.

What is it, why did we change it and how?

libcurl’s rate limiting

libcurl offers the options CURLOPT_MAX_SEND_SPEED_LARGE and CURLOPT_MAX_RECV_SPEED_LARGE on transfers to set the limit in bytes per second for up- and downloads. This is available in the curl tool as command line option --limitrate <speed>. Running