Why does c-ares exist?

A couple of decades ago we started looking for an asynchronous DNS resolver library to use in libcurl. We found none that met our requirements (see below) and started the libdenise project to rectify.

During this work, someone pointed out the ares library and eureka! This was almost exactly what we were looking for. We started expanding it and soon discovered that the ares author wasn't prepared to accept the changes we deemed necessary, and so c-ares was born.


1. Interface

a. Provide both synchronous and asynchronous interfaces.

c. Asynchronous interface: Should be based on non-blocking sockets.

d. Must not use signals as a mean of communication.

2. Queries

a. Must support both IPv4 and IPv6 addresses.

b. Must support hostname and address lookup (A and PTR types)

c. Must support other types of lookup (e.g. CNAME and MX types)

3. Integration

a. Should integrate easily with applications.

4. Portability

a. Must be portable to most commonly used platforms (Linux, Solaris, Win32, etc).

b. Should be portable to as many platforms as possible.

c. Should not rely on hardware or compiler specifics, e.g. endianess and size/alignment of primitive types.

d. Should be no worse, and optimally better than the system's native resolver. (still work to do on this, such as supporting mDNS, DoH, and domain-specific queries)

5. Multi-threading

a. Must not require multi-threading.

b. Must work correctly in multi-threaded environments.

6. Licensing

a. Must allow use in Open Source and proprietary projects.