On Thu, 29 Jul 2004, Edward Lewis wrote: > At 11:32 -0400 7/29/04, Kevin Darcy wrote: > > >I would argue that if an application is using the results of a previous DNS > >lookup which it has stored in memory, then that is "caching" by any meaningful > >definition of the term. And if an app is caching, we should provide a way for > >the app to do so in a coherent manner. This implies making the TTL visible. > >Whether this is in getaddrinfo() or some other API, I'm not qualified to > >comment. > > Yes, it is caching by the application and it is up to the application > to decide how long it will internally cache the data. (Will SSH > close a connection after 8 hours because it feels the original lookup > data is no longer fresh enough?) > > The DNS TTL though is not a good measure of freshness - by that I > mean freshness at the authoritative source. E.g., on one run an SSH > client might get an address via a cache that had to get a fresh > authoritative answer. In this case, the DNS TTL might be 10800. On > a later run, the same client may get the same address - but following > an HTTP client lookup by an hour. In this case, the TTL is now 7200. [...]
I don't think the "freshness" is the point here -- at least not for me. Rather, it's "the minimum how long the DNS server asserts that this address corresponding to the name I asked will be valid". Rather than discarding the result after the TTL would expire, and breaking connections (or whatever), the application could re-query the record after TTL expires to see if it still points to the same address(es). And if the TTL it received now is signficantly larger (e.g., because a cache returned a very low TTL), the new TTL would be longer, leading to a longer time before the next query. An interactive client-application like SSH is a bit bad example of this. Instead, consider an SSH daemon which is configued to listen to the hostname "server.example.net" (not a wildcard address). The daemon could run for a month or a year in one go, but the hostname might change during that time. It could be beneficial that the application could re-query the DNS for "server.example.net" at some intervals (TTL could be one indicator here), and change its bindings if the DNS changes. 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). There are probably better examples as well.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
