Rather, it's "the minimum how long the DNS server asserts that this address corresponding to the name I asked will be valid".
This is what I am afraid of. ;)
A DNS server makes no assurance of the accuracy, etc., of the data it serves. The server makes no temporal statement of the data either. (DNSSEC only "protects" the transfer of data from where the administrator enters it to the resolver that last performs the check.)
Also, the servers are not the (ultimate) authority for the data. They are just the "publication" mechanism. (That's when DNSSEC has something else sign the data, and has the authoritative servers load signed data.)
Statements like "DNS server asserts...will be valid" indicate expectations of what DNS does that are higher than reality. DNS is just a plain old, vanilla look up service.
Similarly, consider a mechanism like SCTP or HIP which ties multiple addresses to a connection. A hostname might map to 1..N addresses when the connection is established; during the lifetime of the connection, the hostname could change to point to an entirely different set of addresses. Depending on how the new addresses corresponding to the end-points are discovered during the session, this TTL information could be quite useful -- as a means to trigger how often one should poll for new information (instead of an arbitrary interval).
Although DNS is quite capable of carrying changing information (thanks to dynamic update), I don't think any application would be wise to rely on polling DNS to discover changed data. That an application element needs to get new data from the DNS ought to be triggered by an event internal to the application (such as a sudden failure of one application element in hearing from a remote element).
There are probably better examples as well..
And this is another troubling statement to me. The SIKED BOF said the same thing and we got grilled. Unless we have a good taxonomy of how DNS is going to be fit under applications, it's hard to know that we are designing a "level above DNS" that is as level a playing field as the DNS interface.
This entire thread is from my reacting to the desire to expose the TTL from the resolver to application. My message is mostly one of concern - that applications need to understand what the TTL means. From my experience (going back in time), I'd try to avoid the TTL as a meaningful interface element - perhaps just from the principle of network layering. If you view the application as a layer above DNS, then using DNS internal data (the TTL) is a "layering violation."
Even if it seems tempting...
Remember - TTL's don't account for the rapidity of dynamic updates - and I think that's more important in the example you've described.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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
