On 10/5/09 2:00 PM, "Russ Allbery" <[email protected]> wrote: > David Boyes raised the excellent point that this draft doesn't talk about > TTLs. As I suspect everyone reading this list already knows, once an > existing AFS client decides on a VLDB server to talk to, it never redoes > the DNS query and hence isn't going to honor TTLs on SRV records. > > I think we have two options: document this behavior, or specify something > more fully correct that requires that the AFS client know the TTL (could > be tricky in a lot of resolver stacks) or redo the query each time it > wants to talk to the VLDB (which seems like a lot of DNS traffic). > Documenting is certainly much easier for existing implementations. > > What do people think?
One thought I had was that most TCP stack implementations these days provide some form of trivial DNS caching, so the impact of lots of DNS lookups may be less than we think -- even the z/OS TCP stack does cacheing these days. If the stack does not cache entries, setting up a caching-only DNS is beneficial to other applications on the same host and may be desirable in general. It looks like both OpenSolaris and some -- if not all -- of the user-oriented Linuxen seem to be headed this way already. Another thought would be to do a SHOULD/MUST division -- recommend that clients SHOULD re-resolve the name each time it looks up the VLDB or other component, but MUST resolve it and select it once at minimum. That way old clients are still in compliance, but over time, the client can be made smarter and/or best practice can be toward some kind of DNS caching on clients as well as servers. The impact of querying a local cache is fairly minimal, and it makes the whole setup a bit more resilient and self-managing. Ultimately, there's some interesting things that can be done with load balancing if TTLs are obeyed, thus the question. -- db _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
