[AFS3-std] DNS SRV Resource Records for AFS

[David Boyes]

On 10/5/09 2:00 PM, "Russ Allbery" <rra@stanford.edu> wrote:
=20
> 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.
>=20
> 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.
>=20
> What do people think?

One thought I had was that most TCP stack implementations these days provid=
e
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.=20

Ultimately, there's some interesting things that can be done with load
balancing if TTLs are obeyed, thus the question.

-- db