The common location lookup mechanism for IM2000 services

In order to locate a particular IM2000 service on Internet, clients may be supplied a domain name. In order to locate the relevant server using that domain name, they perform SRV lookups in the public DNS database, using a variation on the RFC 2782 algorithm.

The service location algoritmn

1. The client prepends the service name (which is defined for each individual service) and the protocol name (_TCP) labels to the supplied domain name to form the DNS question domain name.

2. The client performs a DNS database lookup for the SRV resource record set, of the IN class, for that question domain name.

3. If an answer cannot be obtained, the client takes the service to be temporarily unlocatable and exits the algorithm. Otherwise the client then processes the answer:

   1. If the question domain name does not exist, the client takes the service to be permanently unreachable and exits the algorithm.

   2. If the resource record set is empty (i.e. it contains no SRV resource records), the client takes the service to be temporarily unlocatable and exits the algorithm.

   3. The client sorts the list of resource records into priority order. It then proceeds to process each group of resource records that have the same priority, in ascending priority order:

      1. The client orders the resource records in the group according to weight.

      2. While the group remains non-empty:

         1. The client removes a resource record from the group using the weighted selection algorithm described in RFC 2782.

         2. The client performs the A, AAAA, and equivalent IP address DNS lookups on the target domain name of the removed resource record.

         3. If the target domain name does not exist or has an empty set of IP addresses, the client continues to removing the next resource record from the group.

         4. If the target domain name exists and has a non-empty set of IP addresses, the client sorts the set using local criteria (DNS lookup functions may do this implicitly.) and attempts to contact the service on each IP address and TCP port number in turn until a connection is made.

         5. If the client was able to connect to the service (irrespective of whether it was able to actually communicate using the relevant protocol), it exits the algorithm.

Notes on this algorithm

• IM2000, being entirely new, uses only SRV DNS lookups. It does not fall back to A lookup as the RFC 2782 algorithm does. (Such fallback is impossible. There are, intentionally, no well-known port numbers for IM2000 services. The port numbers are obtained solely from DNS information.)

  Because this lack of fallback in turn removes the ambiguity of "no such domain" errors, IM2000 also treats such errors as "no such service available" indications, and does not employ the ". target" bodge.

• This algorithm does not have the ambiguity of the RFC 2821 section 5 MX lookup algorithm that causes such debate amongst implementors of SMTP Relay clients. Successful connection, irrespective of subsequent communications, terminates the algorithm. Failure to connect causes the algorithm to proceed to the next IP address.

• The lack of fallbacks in this algorithm is a security feature. The fewer alternative DNS mechanisms there are, the less likely it is that a DNS administrator will misconfigure one, causing clients to contact the wrong server.