SRA@XX.LCS.MIT.EDU (Rob Austein) (06/05/86)
(This is going to TCP-IP because the discussion started there. Any
followup should be conducted on NAMEDROPPERS, I think.)
I'd like to (belatedly) second Joe Weening's suggestion that we use
the domain system to supply a contact name service.
If we were designing the Internet from scratch, I'd say to use
Chaosnet style contact names, which are a big win. But we're not
designing from scratch.
Using the domain system would solve two distinct problems that have
arisen lately. One is the contact-names problem under discussion on
TCP-IP, the other is the inadaquacy of the current IN WKS RR format
(see NAMEDROPPERS archives for details).
Here's my proposed RR formats
<service>.<domain-name> IN SERV <ip-address> <port>
<service>.<domain-name> CH SERV <chaos-address>
<Service> is the service name (contact name analog). Domain name is
the name of the host supporting it. <Ip-address> and <chaos-address>
are as in A RRs (note that <chaos-address is two fields, see
NAMEDROPPERS archives). <port> is a 16 bit port number. Chaosnet
doesn't need this, since chaosnet has contact names, but it would be
nice to be able to have a WKS analog for Chaosnet.
The address fields are there for the same reason as in the WKS RR;
some host might offer different services on different network
interfaces. I'm not convinced this is reasonable, but it was
considered necessary in the original WKS format. We might want to add
a <ip-protocol-number> field to the IN class format, same logic (the
analog for Chaosnet would be another text string)
Examples:
SMTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 25
TFTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 69
FILE.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420
TIME.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420
or (with protocols ids)
SMTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 6 25
TFTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 17 69
FILE.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 CHANNEL
TIME.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 SIMPLE
We might also want to put RRs for all the standard services (ie, the
ones known to the protocol czar) in at the root node. This would be
useful for people who want to code with a contact name approach, and
shouldn't be too much overhead.
Queries like {IN SERV *.XX.LCS.MIT.EDU} should work fine and give a
series of RRs listing all funny IP protocols supported by XX.
I think this proposal solves serveral problems without creating any
new ones. It is not the optimal solution to the contact name problem,
but it will work and uses existing technology.
Comments?
--Rob