Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!UCDAVIS.EDU!rdhobby From: rdhobby@UCDAVIS.EDU (Russ Hobby) Newsgroups: comp.protocols.tcp-ip.domains Subject: Experimental DNS RFC (another one: CIP)) Message-ID: <9104082258.AA26036@aggie.ucdavis.edu> Date: 8 Apr 91 22:58:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 360 The following document has been sent to the RFC Editor to be an Experimental RFC (as opposed to being on the standards tract). The RFC Editor has given one week (until Apr 15) to reveiw the document and to say if it is a "good thing". As an experimental RFC the specs are there for people to try it and get some experience with the "experiment". Since there is a Working Group for DNS, the WG has the opportunity to review the document before publication and say if it fits into the plans of the WG. If the WG thinks that experiemental experience will be good, then fine. If the WG has suggestions to the author before making it an experimental RFC, that can be done as well. If the WG thinks that this is something that should be put on the standards tract now, the experimental RFC can be redirected to the WG for review and on to becoming an Proposed Standard RFC in a timely manner. If it goes on to be an experimental RFC now, it can be put into the standards tract by the WG at a later date. Send your comments to me and Greg Vaudreuil (gvaudre@nri.reston.va.us> (since I will be on vacation starting Saturday) and, of course, the WG mail list. Russ Hobby INTERNET: rdhobby@ucdavis.edu IETF Area Director - Applications BITNET: RDHOBBY@UCDAVIS UUCP: ...!ucbvax!ucdavis!rdhobby ------------------------------------------------------------------------- Network Working Group T. Brisco Request for Comments: 12XX Rutgers University Updates: RFCs 1034, 1035 April 1991 CIP DNS Resource Record Status of This Memo This RFC defines an extension to the DNS system [RFC1035] by defining an additional Domain name Specification Resource Record. This RFC specifies an Experimental Protocol and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of the protocol. Distribution of this memo is unlimited. 1. Introduction This memo proposes an extension to RFC1035 [Domain Names - Implementation and Specification]. The extension is a generalized solution to the problem of adequately distributing usage of resources across a series of machines in a "cluster" configuration. The extensions allow the binding of a single name to a series of machines. 2. Description of The Problem In current medium and large scale computer centers, frequently a series of mini- or micro-computers are configured so as to be identically functional to each other; that is, of a series of given workstations a user can log in and be unable to tell any functional differences between it and another member of a cluster. These configurations are typically diskless workstations operating as "clients" from a server using NFS and other protocols to provide a consistent environment to the user across a series of actual machines, or they may be a series of larger time sharing machines clustered together in order to maximize utilization of resources (such as disk space). In all cases, however, all members of the cluster provide the same resources that any other member of the cluster may. In situations where workstations are used, there is rarely a problem finding a machine to work on, users will find a workstation that no-one else is currently using. However, when accessing workstations over the network, or when accessing time sharing machines clustered together, it has been observed that users tend to "bunch up" on a particular machine. In one particular installation, it was noted that one machine typically had more users since it's host name was Brisco [Page 1] RFC 12XX CIP DNS Resource Record April 1991 easier to spell. In order to adequately distribute users across a series of clustered machines, it becomes necessary to extend the concept of a single name bound to a single machine. While there exists facilities to bind multiple names to single machines, there is no convenient way of binding a single name to multiple machines. However, merely binding a single name to multiple machines will not solve the problem at hand - distributing resource utilization with some respect to resource availability. There are two ways to think about this distribution - the method can be either sentient, or non-sentient. The method of distributing the utilization can either be aware of the current demands on the resources of a cluster member or not. In the case of non-sentiency, a pseudo-random method of assigning a user (resource utilizer) to a machine (resource provider) can be used to achieve a somewhat (granular but) even distribution. In the case of sentiency, the entity making the binding between the utilizer and the provider must be aware of the current utilization of the resource provider. 3. The CIP DNS RR This memo provides an extension to RFC 1035 in order to provide a simple, non-sentient method of distributing utilizers amongst providers. This method is not meant to be knowledgeable about the resource utilization on the hosts involved, rather it is meant to be a simple method of randomly distributing utilization across a series of providers. The benefit of these records is that they can be implemented and utilized without any modifications to existing utilities, in addition to being easily implemented. With a random distribution of utilizers across a series of resources, an approximation at utilization balancing can be achieved with a minimum amount of effort. The extension is implemented via a new RR type: TYPE value meaning ---- ----- ------------------------- CIP XX Clustered Internet Pointer The CIP resource records (RR) define a series of names that define a cluster of resources. When responding to requests, the response is a pseudo-random choice of any of the RRs. When a request for a RR comes into the DNS server, the server should first search for the named RR. If the RR is not found, the server should then search for a CIP RR. If a CIP RR is found, the CIP RR Brisco [Page 2] RFC 12XX CIP DNS Resource Record April 1991 should be converted into a CNAME RR, and normal CNAME processing should then ensue. In order to prevent caching by other nameservers, the CNAME RR should have a TTL of 1; however, the RR found in the additional information should have a TTL as defined in RFC1035. If the particular RR is found to be associated with a cluster name, no CIP processing should occur, and the RR should be returned immediately (note that it does not make sense to associate an A record with a cluster). For compatibility with software conforming to only RFC1035, when the DNS server responds after finding a CIP RR and the requested RR, the response should indicate the binding between the cluster name and the RR is that of a CNAME. The only time when a CIP RR should be returned is when the requested RR is of the types CIP, "any" or "*". In this case ALL RRs (CIP or otherwise) should be returned. This is to support future DNS implementations that may support a more "sentient" method of determining host selection. Each time that a cluster name with CIP RRs is processed, the CIP RRs should be reordered using some pseudo-random algorithm. However, implementors are warned that the algorithm should be as fast as possible since the lookup of RRs is usually time critical. In the initial implementation the author used a simple round-robin algorithm. Since CNAME RRs may point at a CNAME RR, CIP RRs may point at other clusters. The ability to define clusters of clusters is inherent in the CIP RR processing, since at any given level the DNS is only resolving CNAME RRs. However, this method of resolving clusters leads to some inherent ambiguity. It is necessary to define to a certain extent how the CNAME processing should be handled. For example, when attempting a MX RR lookup on a cluster; if the first CIP, at the next level of resolving, has no MX RR, should the DNS server check the next CIP in the cluster sequence or return the A RR associated with the resolved CIP? The general rule of thumb should be that at any level of the resolving, the CIP RR processing should be treated as CNAME RR processing. If the requested RR does not exist with the host information specified by the CNAME, the a failure should be returned for the lookup of the initial record. | | v does RR exist? (yes) ----> return RR (no) | | v Brisco [Page 3] RFC 12XX CIP DNS Resource Record April 1991 does CIP RR exist? (no) ----> return FAIL (yes) | | | v randomize and retrieve CIP | | v convert CIP to CNAME set TTL to 1 resolve CNAME RR Since it is possible that administrators may cluster together machines of varying power, there is an optional parameter to the CIP RR indicating the respective "weight" of a host associated with a CIP RR. This is to allow particular resource providers to be "found more frequently" than others. This parameter defines, essentially, how many times the CIP record is found in the cluster. It is not an error for the same CIP record to occur twice in a cluster. If no weight is indicated for the CIP RR, then a weight of 1 is assumed. The full syntax of the CIP RR is as follows: IN CIP name [weight] 4. Examples of Configuration For clarity, examples utilizing the BIND implementation of DNS follow. ------ An average entry might look like: cluster in cip rsrc1 in cip rsrc2 in cip rsrc3 in cip rsrc4 rsrc1 in a 128.6.7.38 rsrc2 in a 128.6.18.34 rsrc3 in a 128.6.4.4 rsrc4 in a 128.6.7.39 This would cause the name "cluster" to be resolved to the addresses associated with rsrc1, rsrc2, rsrc3, and rsrc4 with fairly equal distribution. Brisco [Page 4] RFC 12XX CIP DNS Resource Record April 1991 ------ A cluster entry for machines of different power might look like: cluster in cip vax8650 7 in cip vax750 3 in cip vax730 vax8650 in a 128.6.61.3 vax750 in a 128.6.3.27 vax730 in a 128.6.1.10 This would cause the "vax8650" to be found (on the average) 7 times as frequently as the "vax730", and nearly twice as frequently as the "vax750". ------ An entry like: bunch in cip vax1 in cip pyr1 in cip sun1 in mx mailmachine in hinfo Admin. Center Time Sharing Computers vax1 in a 128.6.69.10 in mx mailmachine1 pyr1 in a 128.6.18.22 in mx mailmachine2 sun1 in a 128.6.12.65 in mx mailmachine3 would evenly distribute the usage across the machines "vax1", "pyr1", and "sun1". Mail addressed to users at "bunch" would be delivered at "mailmachine" since the MX associated with the cluster would always be found first. Mail addressed to users at "vax1", "pyr1", and "sun1" would all be delivered to the respective hosts indicated in the MX RRs. 5. Security Considerations Security issues are not discussed in this memo. Brisco [Page 5] RFC 12XX CIP DNS Resource Record April 1991 6. Author's Address Thomas P. Brisco Rutgers University Computing Services Hill Center for the Mathmatical Sciences Busch Campus P.O. Box 879 Piscataway, New Jersey 08855-0879 Phone: 908-932-2351 EMail: brisco@RUTGERS.EDU Brisco [Page 6]