earle@mahendo.Jpl.Nasa.Gov (Greg Earle) (04/11/88)
[ This is probably not the best place for this. I couldn't come up with
a better one, though, other than `Namedroppers'. Apologies in advance ... ]
I have an interesting possible scenario, and would like to solicit suggestions
regarding choosing a domain to reside under. To wit:
Currently, I access the known Universe and my beloved Internet connection via
an account on this machine [mahendo.JPL.NASA.GOV]. Let's say I am about to
begin work for the `Moon' company. The Moon company has a registered domain,
Moon.COM. There are several sub-domains under Moon.COM, for simplicity's
sake let's choose geographically based ones - West.Moon.COM, East.Moon.COM, &c.
I will be provided with a machine in order to perform my job duties. Under
ordinary circumstances, I could expect to name this machine `gregsbox', and
nestle comfortably under the name `gregsbox.West.Moon.COM' with an MX record
handled by Moon.COM. On the other hand, say the loss of my Internet connection
proves too great to handle (*sniff*). I then cajole the good folks at JPL who
administer the JPL.NASA.GOV domain into letting me set up a SLIP link with
them. Now, this becomes easy, since JPL.NASA.GOV is neatly subdivided into
Class B subnets. Merely by choosing a machine on the backbone net without
an existing subnet farm, a TrailBlazer SLIP link between the my machine and
somebackbonebox.JPL.NASA.GOV gets me onto a new JPL-Net subnet. Thus, just
by running `routed' I become known to the rest of the world (by proxy) because
of their current subnet set-up. So, if I chose, I could also easily nestle
into `gregsbox.JPL.NASA.GOV' with some Internet address containing 128.149.s.h.
In other words, from a *connectivity* and *network* standpoint, such a
circumstance would point to being a member of the JPL domain. But from an
*organizational* standpoint (i.e., who I *work* for), it would point to
staying inside the Moon.COM domain.
Given this scenario, how does one choose which domain to reside in? N.B.:
I realize that with some point-to-point links such as this, that there are
plenty that retain the organizational-oriented domain name. But given that
the network address would be one that is under JPL's network domain (i.e.,
`128.149' is JPL-Net's and JPL-Net's alone), I don't know how this would
affect this decision. Any help?!?
--
Greg Earle earle@mahendo.JPL.NASA.GOV
Indep. Sun consultant earle%mahendo@jpl-elroy.ARPA [aka:]
(Gainfully Unemployed) earle%mahendo@elroy.JPL.NASA.GOV
Lake View Terrace, CA ...!{cit-vax,ames}!elroy!jplgodo!mahendo!earlepostel@VENERA.ISI.EDU (04/11/88)
Greg Earle: Domain names are totally independent of networks. If the JPL network manager was agreeable there is no reason you couldn't have "gregsbox.West.Moon.COM" connected to 128.149.s.h. --jon.
philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) (04/12/88)
(I think you were right about namedroppers being more appropriate...) Anyway, you are mixing apples and oranges. A name (even a domain name) can be arbitrarily bound to an address. The fact that you are on JPL's subnet has no bearing on what domain you put your host into... -Philip
jqj@HOGG.CC.UOREGON.EDU (04/12/88)
>A name (even a domain name) can be arbitrarily bound to an address.
It is worth recalling one respect in which this is not quite accurate.
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.
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.chris@GYRE.UMD.EDU (Chris Torek) (04/12/88)
Note, though, that if your host name is `home.MegaCorp.COM' but is really attached to `res.ear.ch.EDU', but the ch.EDU server does not also serve for MegaCorp.COM, when MegaCorp.COM (or COM in general) is unreachable, ch.EDU sites will not be able to figure out who you are. Having experienced a miniature version of this situation (the official UMD.EDU servers are one broadband-hop away from the Computer Science Department cable, and the local construction folks like nothing better than to cut through broadband cables while pretending to dig up parking lots :-) ), where none of our `cs.umd.edu' machines could call any `umd.edu' machines---which includes all our multi-user hosts---by name. (Fortunately, we still had call by address, if not by value :-) ) Chris
chris@GYRE.UMD.EDU (Chris Torek) (04/12/88)
Oh dear, I just mailed a sentence fragment. What I had meant to say is that not being able to address your machines by name tends to be an unhappy situation. (Just look what happens when you allow yourself to be distracted by grammatical arguments occurring in your office. Bam, you send off a letter chock full o' grammatical errors.) Chris
philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) (04/12/88)
(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