Why norcal.ampr.org does not exist
Zu Dokumentationszwecken folgt hier ein Ausschnitt aus der „tcp-group“-Mailingliste. Ende der 1980er Jahre diskutierten Brian Kantor und andere über die Notwendigkeit von Subdomains innerhalb von „ampr.org“:
Date: Thu, 1 Jun 89 09:11:30 PDT From: brian@ucsd.edu (Brian Kantor) Message-Id: <8906011611.AA14158@ucsd.edu> To: pacbell!noe!marc Subject: Why 'norcal.ampr.org' does not exist. (again) The problem with 'callsign.norcal.ampr.org' (or any other regional or organizational subdomain in ampr.org) is that it's both counterintuitive and unnecessary to name a host that way. A fully-qualified domain name consists of all parts of a hostname up to the implied root of the domain tree. Thus 'wombat.ucsd.edu' is fully qualified and it is unique - there is only one 'wombat' in the 'ucsd.edu' domain, and there is only one 'ucsd' in the 'edu' domain, and there is only one 'edu' at the root of the domain tree. Similarly there is only one 'org' at the root, one 'ampr' in 'org', and since callsigns are unique worldwide, only one 'wb6cyt' in 'ampr.org'. There is no reason to add in a regional domain name somewhere along the line; there will NEVER be another 'wb6cyt', nor another 'u2mir', etc. Thus 'norcal' is unnecessary. When your hostname is in the same domain as the hostname that you wish to refer to, you may omit the common parts. Thus here at UCSD I may refer to 'wombat.ucsd.edu' simply as 'wombat'; the 'ucsd.edu' part is assumed because it is common to both it and my hostname. Similarly, I can refer to any amateur station in the world simply by using its callsign; 'w1aw' is unique, as is 'wn6cum' or 'ua3xyz'. I do NOT have to specify the country, state, geographical reference, etc. 'u2mir in earth orbit' isn't necessary to uniquely identify the station. In fact, were some geographical or organizational reference required, it would be counterintuitive: when I wanted to refer to KB1UK, would I have to specify Rhode Island, which my callbook lists as his mailing address, New Mexico which is where his permanent station location is, UCSD where he lives when he is attending classes during the school year, or the South Pole, where he currently is? And how would I know? To require a geographical subdomain in order to specify a hostname requires the I have some way to KNOW what that subdomain is ahead of time - and that is knowledge that I simply do not have for the majority of stations, and certainly not when first attempting to contact them. Organizational references would be worse: would I have to know whether you consider your primary affilition to be the ARRL, AMSAT, or LuNaTiC before I could contact you? And that's why most of us don't support regional or organizational subdomains within AMPR.ORG. As for multiple hosts per callsign, that is handled by making a CALLSIGN subdomain, and placing the hosts within it: pc.wb6cyt.ampr.org, 3b2.wb6cyt, etc, and always providing ONE of them with a nickname the same as the domain - so that an attempt to contact wb6cyt.ampr.org becomes a contact with whichever machine I (as wb6cyt) have designated as the machine to do that. Using MX (Mail eXchanger) records in the nameserver system, I can even give a LIST of hostnames (in preference order) for your software to try when making mail deliveries. Brian Kantor WB6CYT UC San Diego brian@ucsd.edu ------------------------------ Message-Id: <8906020612.AA02531@erendira.arc.nasa.gov> To: brian@ucsd.edu (Brian Kantor) Cc: tcp-group@ucsd.edu Subject: Re: Why 'norcal.ampr.org' does not exist. (again) In-Reply-To: Your message of Thu, 01 Jun 89 09:11:30 -0700. <8906011611.AA14158@ucsd.edu> Date: Thu, 01 Jun 89 23:12:40 -0700 From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov> Brian, I agree with the gist of your argument, but in a practical sense, I think subdomains are needed. Do you really think that you can have one or 2 nameservers for ampr.org that contain RR's for EVERY station? That's going to be huge and unwieldy to manage. It's like having all systems at universities have unique names and be directly in the edu domain. It's certainly doable, but not practical. Then there is the problem of having AMPRNET not connected, and thus possibly not being able to reach top level servers to get such information. Having local regional nameservers makes it easier to reach them, and easier to deal with all the connectivity problems we have (Class A net number not helping). Thanks, Milo ------------------------------ Date: Fri, 2 Jun 89 08:47:21 PDT From: brian@ucsd.edu (Brian Kantor) Message-Id: <8906021547.AA15875@ucsd.edu> To: tcp-group Subject: Nameservice for AMPR The plan is to have a few (two for now) 'master' nameservers, and lots of regional nameservers. This will work while the network is small. The real difficulty is that the design of the DNS doesn't include the concept of what we need to do - which is to regionalize the database without having to compartmentalize the namespace by using subdomains. What we need is the ability to do zone transfers for pseudo-zones and assemble them into one large zone. I can solve the problem (after a fashion) by making lots of subdomains and transferring those to the master server, then analyzing the data received and creating top-level CNAME RRs for every entry in the subdomains. Such a solution might well work; it wouldn't work well, and the concept horrifies me. I'm open to ideas to solve the problem, but I refuse to bend the human interface to fit an improper solution - and that's the position you're suggesting. Remember that the computer is here to solve our problems, not we its. - Brian ------------------------------ Date: 4 Jul 91 13:46:12 GMT From: brian@ucsd.Edu (Brian Kantor) Subject: Why is the ampr.org namespace flat? To: mail-tcp-group@ucsd.edu The AMPR.ORG namespace is flat at the first level so that using it will be the same as using callsigns. There is NO NEED to make it more complex, since callsigns are already unique worldwide. So, you can have wb6cyt.ampr.org pc.wb6cyt.ampr.org Other than typing exercise, why would you want it otherwise? Remember, names are not routes. Names imply addresses. Addresses are not routes either. I'm sorry to report: it's a bad idea. Let's just gently forget about it. - Brian ------------------------------ Date: 6 Jul 91 05:24:48 GMT From: brian@ucsd.Edu (Brian Kantor) Subject: Why is the ampr.org namespace flat? To: mail-tcp-group@ucsd.edu Just because we're currently using the hack of routing network 44 as though it were a bunch of subnets doesn't mean we'll always be doing that. I believe that routing should be taking place at the transport (AX.25) level, below the IP level, and that would make the IP address space flat too. Someday we may be able to do it. - Brian