@DCN6.ARPA:dcn6.arpa@LINKABIT (11/19/85)
From: dcn6.arpa@LINKABIT
Folks,
A unique opportunity may have come up to get in on the ground floor of the
rapidly-proliferating DARPA Domain Name System (DNS). This system provides
a hierarchically compartmented name-to-address translation function to be used
eventually by all Internet hosts. If some subset of us begin using IP/TCP on a
regular basis, then DNS is the way the rest of the world would know how to
reach us for mail or any other service. It could also be the way we tell them
and each other about our names and addresses and possibly digipeater routes.
The DNS operates using a hierarchically managed name space of the form
<domain-(n)>.<domain-(n-1)>.<...>.<domain-(0)>
where the tree is read starting from the right. Thus, W3HCF.FCC.CCIR.ITU.UN
might be one way to represent my station, the callsign of which is assigned by
the FCC, whose bag of callsigns is allocated by the CCIR, ITU and then UN in
increasing level of scope. However, this is only one of many ways the
delegation of naming authority can be managed, so an equally acceptable name
or "proliferated callsign" might be W3HCF.AMRAD.US. It is a rule, however,
that the top-level rightmost) domain must represent either a two-letter ISO
country code (e.g. US) or one of several organizational or multinational
entities.
Individual Internet hosts (in our case stations) query the DNS data base
either via virtual circuits or datagrams in a hierarchical fashion. Absent
information to the contrary, they start at certain well-known "name servers"
implemented perhaps on local-area gateways. These name servers interpret as
much of the rightmost end of the name as they can. If the name is found
locally, they respond directly with the requested information; while, if not,
they hand off to other name servers, ultimately to one of the "root name
servers" on the ARPANET or elsewhere.
Let's say sombody in San Diego asked the local gateway for W3HCF.AMRAD.US,
which knows nothing about the AMRAD sub-domain, but does know a path to the
root name server at the Network Information Center (NIC) host on ARPANET and
MILNET. NIC finds AMRAD as a duly-registered sub-domain of US and hands off to
the AMRAD name server implemented on a local BBS in the Washington, DC, area.
AMRAD, which registers some or all of the local packeteers, then hands out
Internet address 128.4.1.1 and digipeater route WB4JFI-5 directly to the
requestor, who saves the information for future use. In the presumed temporary
absence of global routing facilities, the IP local-route option I suggested
recently could be used to waft IP datagrams from the originator to the
destination IP gateway via the backbone system (whatever that means) and then
via the AX.25 channel to W3HCF.
There is a lot of technical information on how the DNS works and many
interesting scenarios on how it could be adapted for efficient operation in
the amateur packet-radio community. The DNS is running now on most ARPANET and
many MILNET hosts. DNS name servers are up at least on Unix, TOPS-20 and
Fuzzball hosts. Interested readers can find the details in the DARPA RFC
(Request for Comments) technical memorandum series, which are available in
either electronic or hardcopy form from the NIC. Technical information on the
DNS is described in RFC-881 and RFC-882, while administrational policy is
described in RFC-920.
The purpose of this note is not to propose problems or solutions or even to
argue the merits of the DNS itself, which may come later. At this point in the
development cycle the DNS wizards and "responsible person" (RP) for the
top-level US domain (Jon Postel) are exploring problems created by unusual
applications of the DNS and are receptive to the idea of creating a domain for
amateur callsigns and providing the data-base management functions necessary
to reach gateways for the name servers in the amateur community. What Jon is
asking is an (not necessarily the only) administrative model for an amateur
sub-domain, which requires the following (excerpted from RFC-920):
[begin excerpt]
General Requirements on a Domain
There are several requirements that must be met to establish a
domain. In general, it must be responsibly managed. There must be a
responsible person to serve as an authoritative coordinator for
domain related questions. There must be a robust domain name lookup
service, it must be of at least a minimum size, and the domain must
be registered with the central domain administrator (the Network
Information Center (NIC) Domain Registrar).
Responsible Person:
An individual must be identified who has authority for the
administration of the names within the domain, and who seriously
takes on the responsibility for the behavior of the hosts in the
domain, plus their interactions with hosts outside the domain.
This person must have some technical expertise and the authority
within the domain to see that problems are fixed.
If a host in a given domain somehow misbehaves in its interactions
with hosts outside the domain (e.g., consistently violates
protocols), the responsible person for the domain must be
competent and available to receive reports of problems, take
action on the reported problems, and follow through to eliminate
the problems.
Domain Servers:
A robust and reliable domain server must be provided. One way of
meeting this requirement is to provide at least two independent
domain servers for the domain. The database can, of course, be
the same. The database can be prepared and copied to each domain
server. But, the servers should be in separate machines on
independent power supplies, et cetera; basically as physically
independent as can be. They should have no common point of
failure.
Some domains may find that providing a robust domain service can
most easily be done by cooperating with another domain where each
domain provides an additional server for the other.
In other situations, it may be desirable for a domain to arrange
for domain service to be provided by a third party, perhaps on
hosts located outside the domain.
[end excerpt]
With this note I am inviting discussion primarily on the administrative
points. The technical details, such as how to provide the name servers and
access paths to the Internet, may in fact already be solved.
I would like to propose a first cut at this. A local experimenter's group such
as AMRAD would be nominated to register the amateurs wishing to join the
system. There would be no requirement to join such a group and an amateur
could join any number of such groups. There is no restriction that the members
of the group be drawn from the same geographic area. A sub-domain would be
created for each group and registered in the US domain. Note that I am
specifically not suggesting that an umbrella organization such as the ARRL
take management responsibility for all such sub-domains at this time. An
important concept in the model is that such an organization might in future
take responsibility for just that, in which case some or all of the
sub-domains would be registered in the sub-domain of the organization and the
names might become something like W3HCF.AMRAD.ARRL.US.
An RP must be identified for each sub-domain. I suspect that each group with
sufficient technical horsepower to want to join the DNS now will have many
competent candidates. If future use of the system proliferates beyond the
technical lunatic-fringe of our community, umbrella sub-domains can be
created.
Your comments are invited.
Dave
-------