Re: Thoughts on exposing TTL in more of the ares_parse_*_reply interfaces?

2013/6/30 Mark Delany <e9y_at_bravo.emu.st>

> I see that TTL is missing from most return structures. True, you can
> get it for A/AAAA but not for SRV, PTR and TXT.
>
> I searched the gmane archives but didn't find much, nonetheless, my
> first question is, if this topic has been done to death already, can
> someone point me at the conclusions?
>
> If not, what would be the best way to add TTL visibility? Presumably
> much along the lines of ares_addrttl and friends for those that don't
> have a specific structure, but what about SRV and TXT? Would adding an
> int at the end of these structures be acceptable? (A bit klunky to
> look at, but safe from a binary compatibility POV).
>
> I note that for the TXT case at least, this is problematical because
> ares_parse_txt_reply returns one entry per sub-TXT component rather
> than one entry per TXT. Anyone have thoughts on how best to include
> TTL for that?
>

+1 on adding TTLs in the public API.

I think revamping the parsing functions is a good thing, but just adding
struct members may be a bit unsafe.

I would support new functions to more closely return DNS data (rather
than some high-level mangled subset of the DNS data.) That possibly
relates to the question of how to return A/AAAA records from SRV replies
as well.

-- 
Tommie