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

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

From: Mark Delany <e9y_at_bravo.emu.st>
Date: 30 Jun 2013 20:03:46 +0000

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?

Why is TTL important to me? Largely for DNS-SD implementations where
the use of PTR, TXT and SRV are pervasive and there is a desire to
build small on-board caches for participating devices.

Mark.
Received on 2013-07-01