Well no one ever responded to my email about what is the purpose of ares,
I've gone on to assume that means everyone wants me to define the purpose of
ares :-) and so I've chosen all-purpose general DNS library.

Anyway, I was doing some googling, and I saw an interesting patch for ares.
This patch included a function, ares_parse_reply. This function is a generic
DNS reply parser. Unfortunately, the version in the patch was poorly written
and only included support for about 3-4 record types.

I have taken up the task of trying to expand this to as many record types as
I can figure out the format for. So far, it can parse A, CNAME, NS, MX, PTR,
AFSDB, SOA, and SRV (the original patch also had TXT, but the TXT record
support was broken). I got the inspiration to do this after someone asked
how to use c-ares to get an SRV record. The syntax for this new function is:
int ares_parse_reply(unsigned char *abuf, int alen, int count, struct
ares_record *record);
abuf - The result buffer returned by the DNS query
alen - The length of the result buffer
count - The maximum number of records to return, 0 indicates "all". This is
useful if, for example, you do a query for a T_A, which returns 10 results,
but you only need 3. Parsing all 10 into a struct would be wasteful if you
only need the first 3.

With this function you'd simply do:

ares_query(theChannel, "_http._tcp.somedomain.com", C_IN, T_SRV, callback,
"_http._tcp.somedomain.com");
...

void callback(void *arg, int status, unsigned char *abuf, int alen)
{
    ares_record rec;
    ares_parse_reply(abuf, alen, 1, &rec);
    /* Verify we have an SRV as the response */
    if (rec->type != T_SRV)
        return;
    printf("SRV record:\tpriority: %d\tweight: %d\tport: %d\ttarget: %s\n",
rec->data.srv->priority, rec->data.srv->weight,
            rec->data.srv->port, rec->data.srv->target);
    ares_free_reply(&rec);
}

In my mind, for a user, that makes life MUCH easier. Something tells me
Ben-Pinchas Ornit (the user asking about SRV records), would much rather
just call ares_parse_reply than have to handle all the parsing himself. I
don't think, simply because a user wants to use c-ares, that means the user
has to have an intimate knowledge of the DNS protocol. ares_parse_reply
would solve this by parsing the result into a nice, easy to understand,
structure that the user can easily access.

There is only one problem with the ares_parse_reply function. The
documentation will be ugly. To make it record independant requires the
"data" member of ares_record to be a union. This union contains one member
for each record type. As a result, this will make the documentation complex
as we will need to document the parameters of each of the record types.

>From this, I plan to implement a new function, ares_gethostbyservice. This
function would work similarly to ares_gethostbyname, except that it would
first do a query for a T_SRV, then, it would capture the target of the SRV
record and fo a T_A query for that. Then the callback would be passed the
hostent for the T_A as well as an int for the port number the service is
running on. Then from there, a new CURLOPT_CHECKSRV (or something like that)
would be added. If set, instead of using ares_gethostbyname, libcurl would
use ares_gethostbyservice. It would then use the returned IP/port
(overriding the port specified by the user), to complete the transmission.

Overall, I think this will make c-ares, and libcurl much more robust.

I'm pretty much writing this email just to see if people think it's a good
idea. Right now I've only added support for 8 record types, so if people
think it is stupid, I can easily stop now. I'd hate to have coded support
for 30+ record types and then have Daniel say it's a bad idea :) I've
attached a preliminary version of the patch, just so other's can look at it
and see if they like what I'm doing. It's far from complete right now, I
need to add the "count" parameter, and support for many more record types,
but I think this is definately a step towards making c-ares better.

Anyone have any comments/suggestions on this?

Dominick Meglio