DNS-over-HTTPS (DoH) is being designed (it is not an RFC quite yet but very soon!) to allow internet clients to get increased privacy and security for their name resolves. I’ve previously explained the DNS-over-HTTPS functionality within Firefox that ships in Firefox 62 and I did a presentation about DoH and its future in curl at curl up 2018.
We are now introducing DoH support in curl. I hope this will not only allow users to start getting better privacy and security for their curl based internet transfers, but ideally this will also provide an additional debugging tool for DoH in other clients and servers.
Let’s take a look at how we plan to let applications enable this when using libcurl and how libcurl has to work with this internally to glue things together.
How do I make my libcurl transfer use DoH?
There’s a primary new option added, which is the “DoH URL”. An application sets the CURLOPT_DOH_URL for a transfer, and then libcurl will use that service for resolving host names. Easy peasy. There should be nothing else in the transfer that changes or appears differently. It’ll just resolve the host names over DoH instead of using the default resolver!
What about bootstrap, how does libcurl find the DoH server’s host name?
Since the DoH URL itself typically is given using a host name, that first host name will be resolved using the normal resolver – or if you so desire, you can provide the IP address for that host name with the CURLOPT_RESOLVE option just like you can for any host name.
If done using the resolver, the resolved address will then be kept in libcurl’s DNS cache for a short while and the DoH connection will be kept in the regular connection pool with the other connections, making subsequent DoH resolves on the same handle much faster.
How do I use this from the command line?
Tell curl which DoH URL to use with the new –doh-url command line option:
$ curl --doh-url https://dns-server.example.com https://www.example.com
How do I make my libcurl code use this?
curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL,
"https://curl.haxx.se/");
curl_easy_setopt(curl, CURLOPT_DOH_URL,
"https://doh.example.com/");
res = curl_easy_perform(curl);
Internals
Internally, libcurl itself creates two new easy handles that it adds to the existing multi handles and they are then performing two HTTP requests while the original transfer sits in the “waiting for name resolve” state. Once the DoH requests are completed, the original transfer’s state can progress and continue on.
libcurl handles parallel transfers perfectly well already and by leveraging the already existing support for this, it was easy to add this new functionality and still work non-blocking and even event-based correctly depending on what libcurl API that is being used.
We had to add a new little special thing that makes libcurl handle the end of a transfer in a new way since there are now easy handles that are created and added to the multi handle entirely without the user’s knowledge, so the code also needs to remove and delete those handles when they’re done serving their purposes.
Was this hard to add to a 20 year old code base?
Actually, no. It was surprisingly easy, but then I’ve also worked on a few different client-side DoH implementations already so I had gotten myself a clear view of how I wanted the functionality to work plus the fact that I’m very familiar with the libcurl internals.
Plus, everything inside libcurl is already using non-blocking code and the multi interface paradigms so the foundation for adding parallel transfers like this was already in place.
The entire DoH patch for curl, including documentation and test cases, was a mere 1500 lines.
Ship?
This is merged into the master branch in git and is planned to ship as part of the next release: 7.62.0 at the end of October 2018.
This was actually a whole set of small problems that together made the new 
Old readers of this blog may remember my ramblings on 
Over time, we’ve slowly been adjusting the 
The 
