David Boyes <[email protected]> writes: > 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. I think we're simply required to honor DNS TTLs. I'm not sure there's any leeway in the DNS standard for us to do anything else. That means either (for a stupid client) redoing the DNS query for every call and hoping for a local cache or (for a smart client such as the existing OpenAFS implementation) storing the TTL and honoring it. I'm inclined to just say that's required and not provide leeway for doing something else. Jeffrey and I were talking some more about this and there is another decision point: whether to re-randomize the server list by weight for every call or to only do that when the TTLs expire. Currently, we only do that when the TTL expires, but the DNS SRV RFC prefers doing it for every call (although allows us to specify otherwise). My inclination is to allow either for AFS, at least for the time being. Per call is probably better in some sense, but I don't think it's sufficiently better to require implementations do it. The second draft of this proposal will include more detail about how to map priorities and weights to server preference ranks for implementations that use that method, as there's some subtlety and it's worthwhile to spell out a recommendation for how to handle the whole process. That would only be a recommended implementation approach, of course; the MUST requirement is to produce the required outcome, and beyond that the protocol doesn't care how you do it. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
