[AFS3-std] DNS SRV Resource Records for AFS

[Russ Allbery]

David Boyes <dboyes@sinenomine.net> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>