[comp.protocols.tcp-ip.domains] HINFO record consistency

bryan@terminator.cc.umich.edu (Bryan Beecher) (11/28/90)

One problem with trying to use HINFO records for anything useful (at least
on an inter-domain level) is that there isn't very much consistency between
what various hostmasters place in them.  Some are fairly generic like
"SUN" "UNIX" while others are more specific "Sun-3/50" "SunOS 3.5".

Is there any semi-agreed upon convention for putting stuff in HINFOs?
Is there a list of "proper" CPUs and OSs?  (There is a list at the NIC
that's useful for HOSTS.TXT entries, but if I remember correctly, it's
missing things that some people might like to have like Macs, PCs,
Xterminals and other things.)

If there isn't a convention or list already, I'd like to volunteer to
assemble a list of CPUs and OSs suitable for use in HINFO records.
Then if we can keep this list in well-known spots on the Internet,
it might be possible to get people to use it and get some standardization.
And then maybe HINFO records could be used for something worthwhile.

Please post your comments on this; potential list entries should be
simply mailed to me, and I'll start compiling this list.
--
Bryan Beecher, U-M Information Technology Division  (+1 313 747 4050)
Domain:	bryan@terminator.cc.umich.edu  Path: mailrus!terminator!bryan

rickert@mp.cs.niu.edu (Neil Rickert) (11/28/90)

In article <1990Nov27.234016.21510@terminator.cc.umich.edu> bryan@terminator.cc.umich.edu (Bryan Beecher) writes:
>One problem with trying to use HINFO records for anything useful (at least
>on an inter-domain level) is that there isn't very much consistency between
>what various hostmasters place in them.  Some are fairly generic like
>"SUN" "UNIX" while others are more specific "Sun-3/50" "SunOS 3.5".
>
>Is there any semi-agreed upon convention for putting stuff in HINFOs?
>Is there a list of "proper" CPUs and OSs?  (There is a list at the NIC
>that's useful for HOSTS.TXT entries, but if I remember correctly, it's
>missing things that some people might like to have like Macs, PCs,
>Xterminals and other things.)

  The current convention is, I suspect, approximately the following:

	If the computer is one you manage - for example the system
	running the name server - place fairly specific information
	in the HINFO record.

	If the computer is managed by someone else, use vague incomplete
	information, because the person who knows the details (if such a
	person exists) didn't give it to you, and doesn't understand why
	you want it, and probably doesn't want to know what BIND is all
	about anyway, as long as his system works.

>If there isn't a convention or list already, I'd like to volunteer to
>assemble a list of CPUs and OSs suitable for use in HINFO records.
>Then if we can keep this list in well-known spots on the Internet,
>it might be possible to get people to use it and get some standardization.
>And then maybe HINFO records could be used for something worthwhile.

  Good luck in your attempt.  As you can guess from my comments above, I
think your effort is doomed to failure.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (11/28/90)

bryan@terminator.cc.umich.edu (Bryan Beecher) writes:

>One problem with trying to use HINFO records for anything useful (at least
>on an inter-domain level) is that there isn't very much consistency between
>what various hostmasters place in them.  Some are fairly generic like
>"SUN" "UNIX" while others are more specific "Sun-3/50" "SunOS 3.5".
>
>Is there any semi-agreed upon convention for putting stuff in HINFOs?
>Is there a list of "proper" CPUs and OSs?  (There is a list at the NIC
>that's useful for HOSTS.TXT entries, but if I remember correctly, it's
>missing things that some people might like to have like Macs, PCs,
>Xterminals and other things.)

This may be a case of needless standarization.  Not everything worth doing
is worth doing well.  I like to put the maker and model in the CPU entry
since that doesn't change very often.  I use the most generic terms for the
OS since who wants to keep version numbers up to date?

Rather than focus on what is in HINFO records, it may be more useful to
explore where else they can be used.  At UIUC I've arranged to put a
HINFO record that gives the full name of each sub-domain, e.g., 
hinfo cso.uiuc.edu returns

cso.uiuc.edu	CPU = Computing_Services_Office	OS = NONE

This is handy for interpreting the sometimes cryptic abbreviations used.

In the same vein, host 0 in the in-addr.arpa files returns the name of the
subnet, e.g., 0.5.174.128.in-addr.arpa returns uiuc-dcl-net.uiuc.edu.  The
idea is to roll information typically found outside the DNS, /etc/networks
for example, into it.

/pbp
--
         Paul Pomes

UUCP: {att,iuvax,uunet}!uiucuxc!paul   Internet, BITNET: paul@uxc.cso.uiuc.edu
US Mail:  UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801-2910

fuat@cunixf.cc.columbia.edu (Fuat C. Baran) (11/29/90)

In article <1990Nov27.234016.21510@terminator.cc.umich.edu> bryan@terminator.cc.umich.edu (Bryan Beecher) writes:

>Is there any semi-agreed upon convention for putting stuff in HINFOs?
>Is there a list of "proper" CPUs and OSs?  (There is a list at the NIC
>that's useful for HOSTS.TXT entries, but if I remember correctly, it's
>missing things that some people might like to have like Macs, PCs,
>Xterminals and other things.)
>
>If there isn't a convention or list already, I'd like to volunteer to
>assemble a list of CPUs and OSs suitable for use in HINFO records.
>Then if we can keep this list in well-known spots on the Internet,
>it might be possible to get people to use it and get some standardization.
>And then maybe HINFO records could be used for something worthwhile.

I believe RFC1060 "Assigned Numbers" (March 1990) is where machine
names and system names are listed.

The "status" sections says:

   This memo is a status report on the parameters (i.e., numbers and
   keywords) used in protocols in the Internet community.  Distribution
   of this memo is unlimited.

It has sections named MACHINE NAMES (p.53) and SYSTEM NAMES (p.57)

Mahcine names IBM-PC, IBM-PC/AT, etc. are in there, as is MAC-II
(Macintosh?). The system name "X11R3" is there (for X terminals?),
though not X11R4 (yet).

This version obsoletes RFC1010 "Assigned Numbers" (May 1987).
Assigned Numbers seems to get updated yearly, except for the gap
between 1987 and 1990.


						--Fuat
Internet: fuat@columbia.edu          U.S. MAIL: Columbia University
  BITNET: fuat@cunixf                           Center for Computing Activities
    UUCP: ...!rutgers!columbia!cunixf!fuat      712 Watson Labs, 612 W115th St.
   Phone: (212) 854-5128  Fax: (212) 662-6442   New York, NY 10025

enag@ifi.uio.no (Erik Naggum) (11/29/90)

In article <1990Nov28.025352.28252@ux1.cso.uiuc.edu>
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) writes:

   Not everything worth doing is worth doing well.

Agreed, if you know what you're doing.  If you don't know what you're
doing, you don't have any idea of what "well" entails, either.

   At UIUC I've arranged to put a HINFO record that gives the full
   name of each sub-domain, e.g., hinfo cso.uiuc.edu returns

   cso.uiuc.edu	CPU = Computing_Services_Office	OS = NONE

   This is handy for interpreting the sometimes cryptic abbreviations
   used.

This is what the TXT RR is for.  Don't kluge up the Resource Records
when one for the exact purpose you're looking for exists, but you
don't know about it.  RTRFC.  The TXT RR is standardized, but under-
utilized.

   In the same vein, host 0 in the in-addr.arpa files returns the name
   of the subnet, e.g., 0.5.174.128.in-addr.arpa returns
   uiuc-dcl-net.uiuc.edu.  The idea is to roll information typically
   found outside the DNS, /etc/networks for example, into it.

This is the Right Thing to do.  It's even been standardized.

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863
--

enag@ifi.uio.no (Erik Naggum) (11/29/90)

Bryan,

The HINFO values are supposed to be chosen from the list in RFC 1060,
Machine Names (page 53 ff), and System Names (page 57).

From RFC 1035, Domain Names - Implementation and Specification:

    3.3.2. HINFO RDATA format

	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	/                      CPU                      /
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	/                       OS                      /
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    where:

    CPU             A <character-string> which specifies the CPU type.

    OS              A <character-string> which specifies the operating
		    system type.

    Standard values for CPU and OS can be found in [RFC-1010].

    HINFO records are used to acquire general information about a host.  The
    main use is for protocols such as FTP that can use special procedures
    when talking between machines or operating systems of the same type.

Note: RFC 1060 obsoletes RFC 1010.

Note that the strings listed in RFC 1060 break the general syntax
rules found in RFC 1035 for general domain names.  (Space and slash
are not recommended.)

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863
--

enag@ifi.uio.no (Erik Naggum) (11/29/90)

Correction to previous posting.

In article <1990Nov28.025352.28252@ux1.cso.uiuc.edu> paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) writes:

   In the same vein, host 0 in the in-addr.arpa files returns the name of the
   subnet, e.g., 0.5.174.128.in-addr.arpa returns uiuc-dcl-net.uiuc.edu.  The
   idea is to roll information typically found outside the DNS, /etc/networks
   for example, into it.

Paul,

I may have overlooked something.  If you do this with the HINFO RR,
you're wrong.  If you do it with the PTR RR, you're in accordance with
RFC 1101 DNS Encoding of Network Names and Other Types.  If you
haven't read it, please do.  It specifies exactly what you're trying
to accomplish.

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863
--

erik@naggum.uu.no (Erik Naggum) (12/01/90)

> Well, this sounded like an interesting idea, so I went and FTPed the RFC,
> and installed all the stuff in my name server.  I have the following info
> now for domain erg.sri.com, from a "dig erg.sri.com any" request:

[ whole bunch of records deleted ]

I think you missed a small point in RFC 1101.  The idea is to make one
PTR RR for ERG.SRI.COM pointing at your class B network, and vice
versa, but NOT to point to all subnets.  These would have their own
IN-ADDR.ARPA PTR RRs pointing at the proper network name, such as
ERG-SN-1.ERG.SRI.COM for subnet 1.  With the aid of the A RRs for the
network number, you can find those subnets easy enough, anyway.

That is, the PTR RR should be:

erg.sri.com.    86400   PTR     0.0.18.128.in-addr.arpa.

You now have significantly less data to stuff into the reply packet,
and I believe the problems you experience will go away.  :-)

[Erik]

davy@ERG.SRI.COM (12/01/90)

     From:  Erik Naggum <erik@naggum.uu.no>
     Date:  Fri, 30 Nov 1990 22:52:45 +0100
     Subject:  Re: HINFO record consistency 

     
     
     > Well, this sounded like an interesting idea, so I went and FTPed the RFC,
     > and installed all the stuff in my name server.  I have the following info
     > now for domain erg.sri.com, from a "dig erg.sri.com any" request:
     
     [ whole bunch of records deleted ]
     
     I think you missed a small point in RFC 1101.  The idea is to make one
     PTR RR for ERG.SRI.COM pointing at your class B network, and vice
     versa, but NOT to point to all subnets.  These would have their own
     IN-ADDR.ARPA PTR RRs pointing at the proper network name, such as
     ERG-SN-1.ERG.SRI.COM for subnet 1.  With the aid of the A RRs for the
     network number, you can find those subnets easy enough, anyway.
     
     That is, the PTR RR should be:
     
     erg.sri.com.    86400   PTR     0.0.18.128.in-addr.arpa.
     
     You now have significantly less data to stuff into the reply packet,
     and I believe the problems you experience will go away.  :-)
     
     [Erik]

Well, we (erg.sri.com) don't own the class B... that belongs to our parent
domain, sri.com.

But, you're right, I may have misinterpreted something.  I was looking on
page 6 of the RFC, which shows an example for MCC.COM, listing several
nets.  But, now that I look more closely, those are all different class C
nets, not subnets of the same class B.

Guess I'll have to beat on the sri.com administrator to put the top-level
things in, and go take those back out of my files.  Bother.

Thanks,
--Dave