[9] in Hesiod
Re: question about HS class
daemon@ATHENA.MIT.EDU (Win Treese)
Wed Oct 26 23:49:43 1988
To: pma%hpcndm@hplabs.HP.COM
Cc: hesiod@ATHENA.MIT.EDU
In-Reply-To: Your message of Mon, 24 Oct 88 09:16:45 -0700.
Date: Wed, 26 Oct 88 23:23:35 EDT
From: Win Treese <treese@ATHENA.MIT.EDU>
>
> Hi. I've been playing around with the hesiod extensions and came to the
> realization that the TXT type works also for the IN class. Since there
> aren't any data in the HS that have different formats than data in the
> IN class, is the HS class really necessary? The overhead of setting up
> the tree for HS data could be saved ...
> Paul Albitz
> pma%hpcndm@hplabs.hp.com
The HS class was chosen, as I recall, for two major reasons. The first is
more or less aesthetic: we view Hesiod data as different in some sense from
Internet management information. That is, class IN is used for Internet-specific
information (e.g., host addresses, MX information, etc.) and class HS is
for general application use. Technically, the distinction is not strictly
necessary.
The second reason is pragmatic. At MIT, normal name resolution (such as
host addresses) is handled by name servers maintained by MIT Telecommunications,
not by Project Athena. We do not currently maintain Athena hosts in an
ATHENA.MIT.EDU subdomain of MIT.EDU. Hence, maintaining a second tree is
desirable, since it clearly separates the administration of the name servers.
Of course, one could conceivably handle this configuration by delegating the
proper authority to NS.ATHENA.MIT.EDU name servers that use class IN, but that
gets back to the first reason.
Win Treese
Digital Equipment Corp.
Cambridge Research Lab & MIT Project Athena
treese@crl.dec.com, treese@athena.mit.edu
