Why does c-ares exist?

Several years 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 heureka! 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.

b. Synchronous interface: Should support common interfaces, such as gethostbyname() and getaddrinfo(). (this is not fulfilled)

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. Could support other types of lookup (e.g. CNAME and MX types)

3. Integration

a. Should integrate easily with applications, and particularly, their mainloop implementations. (partly fulfilled, still a little too attached to select() )

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.

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.