Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!lts!amanda From: amanda@lts.UUCP (Amanda Walker) Newsgroups: comp.protocols.tcp-ip Subject: Re: HINFO Message-ID: <1117@lts.UUCP> Date: 12 Apr 89 15:01:41 GMT References: <8904102034.AA05495@hogg.cc.uoregon.edu> Reply-To: amanda@lts.UUCP (Amanda Walker) Organization: InterCon Systems Corporation, Reston, VA Lines: 28 Hmm. You can look at a domain name server in two ways. The first is that it replaces the /etc/hosts file under UNIX, that is to say it provides the mapping between ASCII host names and IP addresses. This is currently its primary use most of the time, I admit. However, you can also look at it as a way to determine the attributes of hosts and domains, with the IP address being just one of the attributes. This is how I see it, and from my reading of the RFC, is how it was intended. There are often good reasons for needing to know more than just the IP address of another machine, and in some cases you need to know this even if the machine in question is down (MX records, in particular). A more general host information protocol (HIP? :-)) would be useful, but I still think that it wouldn't replace HINFO and MX records. Maybe we shouldn't need them (in some sense of ``should''), but the fact is that we often do, DNS as it stands does a pretty good job of solving the problem, and extensions such as Hesiod do the same thing for users, mailboxes, and so on. I don't mean to be flippant, but if you know a better way to do it, by all means implement it and write up an RFC... -- Amanda Walker InterCon Systems Corporation -- "A keyboard ... how quaint!" -- Scotty, Star Trek IV: The Voyage Home