Hence I think we could collectively be more effective in fixing this if we could present an API mechanism by which the application/middleware could find out an upper limit on how long time it should retain the information in its own cache.
I've thought about replying to this for some time.
I can see that the DNS TTL would be an appropriate measure of time that an application can "refer to" an answer it got from a DNS lookup - in essence the application is acting like a DNS cache and the TTL applies.
But, that's the limit of how an application ought to make use of the TTL. The TTL isn't a necessarily a measure of the volatility of the data - e.g., it's not an indication of the "mean time to next change," say before the next dynamic update. Another example, the TTL isn't a measure of the useful life of the data - just the amount of time that a cache holding of it is "wise."
DNS can offer up the following times - TTL, end of the signature validity (under DNSSEC), zone expiration. Signature validity can be a measure of the validity of the data's signature or the measure of the validity of the union of the entire chain. (I.e., just the RRSIG for the A record you want, or the "sum" of the times for the root's KEY, TLD's DS and KEY, ..., and the A's validity.)
DNS does not have a "next scheduled change" (like there is in things like X.509 CRLs), which would probably far more interesting to an application.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer
"I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
