Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA01556; Sat, 5 Oct 1996 12:55:00 -0400 Received: by CS.UTK.EDU (bulk_mailer v1.7); Sat, 5 Oct 1996 12:53:47 -0400 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA01478; Sat, 5 Oct 1996 12:53:39 -0400 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA29564; Sun, 6 Oct 1996 02:53:30 +1000 (from kre@munnari.OZ.AU) To: Eric Thomas Cc: drums@cs.utk.edu Subject: Re: cname lookup effort In-Reply-To: Your message of "Sat, 05 Oct 1996 17:30:38 +0200." <199610051546.LAA26120@CS.UTK.EDU> Date: Sun, 06 Oct 1996 02:53:27 +1000 Message-Id: <17872.844534407@munnari.OZ.AU> From: Robert Elz Date: Sat, 5 Oct 1996 17:30:38 +0200 From: Eric Thomas Message-ID: <199610051546.LAA26120@CS.UTK.EDU> My main objection to the current wording in 1123 is that it leaves me me with only one working solution (CNAME), which is unsatisfactory, to the problem of the service-based hostnames vs ISP outsourced box which I mentioned in my last posting. This is a little unbelievable. CNAME accomplishes exactly one productive thing not able to be done other ways via the DNS. There are zillions of unproductive things you can manage with CNAME records (an almighty mess), but just one that is useful. Everything else can be done some other way. The one useful property of a CNAME is that allows rewriting of names - it says "this name is an alias for that other one which is the real name everyone should use". It doesn't even do that particularly well, as it doesn't work for a name wth sub-domains. You're proposing eliminiating the only rational purpose for keeping CNAME records in the DNS at all. It isn't beyond all possibilities that at some stage CNAME records might just be deprecated, eliminating all of these problems. kre