Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!ucbvax!JESSICA.STANFORD.EDU!almquist
From: almquist@JESSICA.STANFORD.EDU ("Philip Almquist")
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Experimental DNS RFC (another one: CIP))
Message-ID: <9104140321.AA05594@jessica.stanford.edu>
Date: 14 Apr 91 03:21:23 GMT
References: <9104082258.AA26036@aggie.ucdavis.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 64

Russ,
	Since nobody else has had much to say on this, and since I don't
know if you saw the message I sent to Dave Crocker, here are my comments
on the proposed CIP resource record (BTW, you might have gotten more of
a response from the Working Group if you'd sent the message to its
current mailing list, which I believe is dns-wg@nsl.dec.com).

	The purpose of the CIP record is to allow a generic name to
refer to multiple, functionally equivalent hosts.  When a DNS server
receives request for the address of such a generic name, it synthesizes
an A record for the generic name giving the address of one of the real
machines.  There are various ways that the DNS server could conceivably
choose which of the real machines to return information about.  The
proposal decrees that the server should use a particular mechanism, a
weighted round robin scheme.

	Something that makes the CIP record rather extraordinary is that
it is basically just a directive telling the server how to function.  A
server will not normally includes a CIP record in any response that it
sends.  This suggests to me that there might be alternative, non-
protocol mechanisms which accomplish the same purpose.

	Indeed, the problem of how to have a generic name for multiple
equivalent hosts was addressed by the DNS Working Group some time ago.
The group found that no new record types were needed or desirable.  CMU
(and probably other places) already do just what the author of the CIP
proposal wants to be able to do, without any extensions to the DNS
protocol.

	How do they do it?  They delegate authority for the generic name
to a special nameserver.  When that special nameserver gets a request
for the address associated with the generic name, it creates and returns
an A record claiming that the address associated with the generic name
is the address of one of the real hosts.  (Actually, there is no real
reason to have the special nameserver be separate from the regular one,
except that it simplified implementation).

	How does the special server decide which address to return?  It
could return the address of the machine with the lowest load average.
It could return the addresses using a weighted round robin scheme (in
which case, it's configuration file could even contain things that look
like CIP records).  Or it could do something else...  The point is that
the answer to the question in the first sentence is what the OSI people
call a "local matter".

	Does the CIP mechanism have any advantage?  Yes, there's a small
one.  Essentially, it standardizes the configuration information about
generic names sufficiently that the config files are portable to other
implementations of the mechanism.  Because the config files also happen
to be zone files, the config information can also be zone transferred to
other implementations.  However, I believe that the costs of the CIP
proposal outweigh its benefits.  The standardization of the config
information for generic names is achieved at the cost of requiring that
anyone using the mechanism has to use weighted round robin (or else
forget about CIP and use the current mechanism).  Additionally, the CIP
proposal would have to be implemented, whereas the current mechanism is
already implemented.

	I can't speak for the DNS Working Group, but my own opinion is
that the CIP record would bloat the standard for little if any real
gain.  If an RFC is to be published on the topic, it should instead
describe the currently used mechanism (and perhaps note where the
existing implementations may be obtained).
							Philip