Taking a look from a somewhat different perspective.

I would appreciate feedback on "Issues to address" near the end of the text.

======================================== analysis:

hosting service means below "volume hosting service"
hosting-service-endpoint means below (numeric-ip,numeric-port)

security implications are noted assuming use of cryptographic
server-to-client authentication and bidirectional data integrity protection
for all path- and file- data transmissions.

The evaluation/mapping from a path to the corresponding contents in Coda:

1. realm => volume location service
   - we need at least one reachable server
     of possibly many,
     more is slightly better,
     all are equally valid,
     the fastest is best
   - the data consistency is sufficiently well governed by TTL
   - the model corresponds (roughly) to what SRV DNS records are
   - tolerable to use unauthenticated service
     (the worst outcome is DOS)

2. [root] volume-name => a list of hosting services' endpoints, each being
                         (ip,port)
   - we need at least one reachable server
     of possibly many
     but more is better,
     all are equally valid,
     the fastest is best
   - should be authenticated client-to-server to avoid information leaks
     (server-to-client spoofing is at worst DOS)

   2.1 volume-name => volume-numeric-id
       - this data is an implementation detail and not relevant for a client
       - no apparent security implications per se

   2.2 volume-numeric-id => list of instances aka replicas, each being
                            (server-numeric-id,volume-id-in-server)
       - we need the data about all of the instances
       - should be authenticated client-to-server to avoid information leaks
         (server-to-client spoofing is at worst DOS)

   2.3 for each instance, server-numeric-id => hosting-service-endpoint
       - tolerable to use unauthenticated mapping service
         (the worst outcome is DOS)

Currently step 1 is implemented via DNS but it does not seem to
provide for any data expiration/renewal (?) besides by manually
running cfs check<something> on a client (?)

In the current implementation all of the 2.x steps are performed
inside the "volume location service" (referred to as VLS below),
which approach has a serious limitation:

- the VLS can not reliably know which endpoint is appropriate for
  a client to contact a certain hosting-service
  (a hosting service process may be available via many endpoints
  with different properties),
  this knowledge should be placed/looked for near the client
  though definitely at a level higher/larger than the client host

The current implementation does not either provide any means
to maintain temporal consistency of the VLS data, there is no
invalidation/expiration/renewal (actually this would not seem hard to add).

I would keep in VLS only the absolutely needed minimum of the functionality
and let auxiliary means handle as much of the mappings as possible.

DNS provides sufficient means to handle the task.

The step 1. is already handled by DNS even though this probably
would benefit of expiration/renewal.

I suggest moving the step 2.3 to the client, to address the limitation
of the current design. The mapping in this step is not security-critical
and hence can be delegated to DNS.

Jan's intention was to split 2.3 into

       2.3.1 server-numeric-id => (f.q.d.n,numeric-port)
             inside the VLS

       2.3.2 f.q.d.n => numeric-ip
             on the clent, via DNS

Which for my eyes keeps a burden on VLS which can/should be delegated to
DNS as well, for reduced complexity and better clarity.

========================================

The issues to address:

- is it actually correct to let server-id be public information?
- may some realms wish to publish VLS servers but justifiably
  not the file servers?

If the answers to these questions is assuring (yes and no respectively)
then what is the best way to use DNS for id->endpoint mapping?

One possibility is to [ab]use the priority field in SRV for server-id
which is simple, efficient and handy for small realms but clumsy for
large ones.

A somewhat cleaner alternative would be introducing SRV records like

_codasrv_N._udp.<realm>      per file server,
                             N being e.g. the server-ID in decimal

This would be straightforward and still scale well (one extra DNS query
per server, once in a while).

Is there a better approach?

It would be also worth to address the confusion which we create by using
_codasrv._udp.<realm>.

The information which we currently publish via DNS is purely for the
volume location service. I would rather switch (of course gradually)
to _codavls._udp instead, and possibly use _codafs or similar when we
mean the file service.  (or _codavl / _codaf ?)

If not otherwise, this would open for splitting volume location
and file services into different processes. Is there any reason
to avoid this? Hopefully not. Would this make the code easier
to understand and maintain? I expect yes.

Regards,
Rune