Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!LARRY.MCRCIM.MCGILL.EDU!philipp
From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC])
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Domain name, domain name, what shalt thou be, domain name?
Message-ID: <8804120254.AA25398@Larry.McRCIM.McGill.EDU>
Date: 12 Apr 88 02:54:26 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 46

(I will be happy to move this discussion to a more appropriate list, if you
wish to continue this "in public".)

	A typical site needs a simple way to generate an INADDR-ARPA database
	from its name->address database.  A many-many map from SOA zones to
	networks makes it hard to automate this generation.

IN-ADDR.ARPA records are undeniable a kludge and an afterthought.  It seemed
that the inverse query was implausible computationally for doing address to
name mappings.  There is no clean solution.  A mapping that is optimized in
one direction can be very hard to compute inversely (such as hashing).

	I think it very undesirable to have lots of hosts with one authority
	for their name->address translation and a different one for
	address->name translation.  In some cases it's necessary, I suppose,
	but the number of such hosts should be minimized so as to maximize the
	modularity of the database.  A much cleaner scheme is to have a host's
	real domain name directly depend upon its network number, and instead
	have a pointer record in the other domain allowing an alias.  The
	domain system as presently defined is sufficiently general to allow
	both schemes; which one gets used becomes a question of taste and
	pragmatics.

If JPL is willing to give him a subnet number, then handling address to
name translation as well shouldn't be putting them out.  What is "desirable"
and "clean" is not always convergent with what is necessary.  Creating "fake"
names to facilitate solutions is hardly a "clean" approach.

Having a host's name depend on its address is an intolerable restriction.
It completely negates the distributed capability of the domain name system.

In the example, you should be able to have:

$ORIGIN s.49.128.in-addr.arpa.
1		IN	PTR	(some name for 1)
2		IN	PTR	(some other name for 2)
...		IN	PTR	(...)
h		IN	NS	Some-Server.Sun.Com.
...		IN	PTR	(...)

in JPL's nameserver for s.49.128.in-addr.arpa and have it point to one
of Sun's nameservers and make it authorative for that particular host.
This would allow the "proper" administration of the name.  But as I said,
you could just as easily have JPL administer the mapping locally.

-Philip