This would break ABI to expose since the data structure are not opaque. At some point we should figure this out, but it isn't going to be easy unfortunately.

I think the cleanest way to provide TTL to users is to introduce new RR parsing functions that return other (extended) structs that contain TTL and possibly even a way to extend the struct in a future.

@markdingo offered a patch for this back in 2013 here: https://c-ares.haxx.se/mail/c-ares-archive-2013-07/0005.shtml

Looks like it didn't get traction at the time, and looks like that patch changed the structs directly which as you mentioned would break ABI.

I'm not an expert, is something like this what you mean for a new struct that could be extended?

struct ares_srv_reply_with_ttl {
  struct ares_srv_reply  *next;
  char                   *host;
  unsigned short          priority;
  unsigned short          weight;
  unsigned short          port;
  int                     ttl;
};

typedef struct ares_srv_reply_with_ttl *ares_srv_reply_with_ttl_ptr;

int
ares_parse_srv_reply_with_ttl (const unsigned char *abuf, int alen,
                      struct ares_srv_reply_with_ttl_ptr srv_out)
{
/* same code as ares_parse_srv_reply but also add ttl */
}

Better yet would be to add a new function that takes an opaque pointer/object, and accessors to the pointer/object to future-proof it in case we want to add anything else in the future. Having a structure as public is always a bad thing to do :/

Bear with me, that's what I had hoped to achieve with the typedef of *ares_srv_reply_with_ttl_ptr; and then the new function that takes it as a parameter: ares_parse_srv_reply_with_ttl. Is that the wrong way to do it? I guess I need to have the actual struct definition in an internal header file and an incomplete definition in the normal header file. Is there anything else to make it private?

I guess I didn't put accessors in there, so they would be like this, right?

char* ares_srv_reply_with_ttl_get_host (ares_srv_reply_with_ttl_ptr srv_reply)
void ares_srv_reply_with_ttl_set_host (ares_srv_reply_with_ttl_ptr srv_reply)

Would it be possible to expose this via ares_gethostbyaddr() as well? We're using that vs bare T_PTR requests in order to also support file lookups along with remote lookups, but the lack of TTL values is causing some other issues.

We've got a new parser as of #581 that will expose all DNS data fields. Its not currently public, but will be soon-ish. I want it to kind of bake behind the scenes for a release or two to make sure there's no needed API changes.

Instead of calling ares_parse_XXX_reply(), you'd call ares_dns_parse() which returns an opaque object with a bunch of accessors for iterating across RRs and extracting data. Currently that is in https://github.com/c-ares/c-ares/blob/main/src/lib/ares_dns_record.h which isn't public, but those routines should be moved into a public header in the future.

The existing ares_parse_XXX_reply() functions are reimplemented as wrappers around the new dns parser so you can see how it extracts the fields it needs, etc.

PR #604 makes this public, closing