💾 Archived View for spam.works › mirrors › textfiles › internet › domain.txt captured on 2023-11-14 at 10:22:55.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
What is a USENET domain?
------------------------
What is a Domain?
Mark R. Horton
Bell Laboratories
Columbus, Ohio 43213
ABSTRACT
In the past, electronic mail has used
many different kinds of syntax, naming a
computer and a login name on that
computer. A new system, called
``domains'', is becoming widely used,
based on a heirarchical naming scheme.
This paper is intended as a quick
introduction to domains. For more
details, you should read some of the
documents referenced at the end.
1. Introduction
What exactly are domains? Basically, they are a way of
looking at the world as a heirarchy (tree structure).
You're already used to using two tree world models that work
pretty well: the telephone system and the post office.
Domains form a similar heirarchy for the electronic mail
community.
The post office divides the world up geographically, first
into countries, then each country divides itself up, those
units subdivide, and so on. One such country, the USA,
divides into states, which divide into counties (except for
certain states, like Louisiana, which divide into things
like parishes), the counties subdivide into cities, towns,
and townships, which typically divide into streets, the
streets divide into lots with addresses, possibly containing
room and apartment numbers, the then individual people at
that address. So you have an address like
Mark Horton
Room 2C-249
6200 E. Broad St.
Columbus, Ohio, USA
(I'm ignoring the name ``AT&T Bell Laboratories'' and the
zip code, which are redundant information.) Other countries
may subdivide differently, for example many small countries
do not have states.
The telephone system is similar. Your full phone number
might look like 1-614-860-1234 x234 This contains, from left
to right, your country code (Surprise! The USA has country
- 2 -
code ``1''!), area code 614 (Central Ohio), 860 (a prefix in
the Reynoldsburg C.O.), 1234 (individual phone number), and
extension 234. Some phone numbers do not have extensions,
but the phone system in the USA has standardized on a 3
digit area code, 3 digit prefix, and 4 digit phone number.
Other countries don't use this standard, for example, in the
Netherlands a number might be +46 8 7821234 (country code
46, city code 8, number 7821234), in Germany +49 231
7551234, in Sweden +31 80 551234, in Britain +44 227 61234
or +44 506 411234. Note that the country and city codes and
telephone numbers are not all the same length, and the
punctuation is different from our North American notation.
Within a country, the length of the telephone number might
depend on the city code. Even within the USA, the length of
extensions is not standardized: some places use the last 4
digits of the telephone number for the extension, some use 2
or 3 or 4 digit extensions you must ask an operator for.
Each country has established local conventions. But the
numbers are unambigous when dialed from left-to-right, so as
long as there is a way to indicate when you are done
dialing, there is no problem.
A key difference in philosophy between the two systems is
evident from the way addresses and telephone numbers are
written. With an address, the most specific information
comes first, the least specific last. (The ``root of the
tree'' is at the right.) With telephones, the least
specific information (root) is at the left. The telephone
system was designed for machinery that looks at the first
few digits, does something with it, and passes the remainder
through to the next level. Thus, in effect, you are routing
your call through the telephone network. Of course, the
exact sequence you dial depends on where you are dialing
from - sometimes you must dial 9 or 8 first, to get an
international dialtone you must dial 011, if you are calling
locally you can (and sometimes must) leave off the 1 and the
area code. (This makes life very interesting for people who
must design a box to call their home office from any phone
in the world.) This type of address is called a ``relative
address'', since the actual address used depends on the
location of the sender.
The postal system, on the other hand, allows you to write
the same address no matter where the sender is. The address
above will get to me from anywhere in the world, even
private company mail systems. Yet, some optional
abbreviations are possible - I can leave off the USA if I'm
mailing within the USA; if I'm in the same city as the
address, I can usually just say ``city'' in place of the
last line. This type of address is called an ``absolute
address'', since the unabbreviated form does not depend on
- 3 -
the location of the sender.
The ARPANET has evolved with a system of absolute addresses:
``user@host'' works from any machine. The UUCP network has
evolved with a system of relative addresses: ``host!user''
works from any machine with a direct link to ``host'', and
you have to route your mail through the network to find such
a machine. In fact, the ``user@host'' syntax has become so
popular that many sites run mail software that accepts this
syntax, looks up ``host'' in a table, and sends it to the
appropriate network for ``host''. This is a very nice user
interface, but it only works well in a small network. Once
the set of allowed hosts grows past about 1000 hosts, you
run into all sorts of administrative problems.
One problem is that it becomes nearly impossible to keep a
table of host names up to date. New machines are being
added somewhere in the world every day, and nobody tells you
about them. When you try to send mail to a host that isn't
in your table (replying to mail you just got from a new
host), your mailing software might try to route it to a
smarter machine, but without knowing which network to send
it to, it can't guess which smarter machine to forward to.
Another problem is name space collision - there is nothing
to prevent a host on one network from choosing the same name
as a host on another network. For example, DEC's ENET has a
``vortex'' machine, there is also one on UUCP. Both had
their names long before the two networks could talk to each
other, and neither had to ask the other network for
permission to use the name. The problem is compounded when
you consider how many computer centers name their machines
``A'', ``B'', ``C'', and so on.
In recognition of this problem, ARPA has established a new
way to name computers based on domains. The ARPANET is
pioneering the domain convention, and many other computer
networks are falling in line, since it is the first naming
convention that looks like it really stands a chance of
working. The MILNET portion of ARPANET has a domain, CSNET
has one, and it appears that Digital, AT&T, and UUCP will be
using domains as well. Domains look a lot like postal
addresses, with a simple syntax that fits on one line, is
easy to type, and is easy for computers to handle. To
illustrate, an old routed UUCP address might read
``sdcsvax!ucbvax!allegra!cbosgd!mark''. The domain version
of this might read ``mark@d.osg.cb.att.uucp''. The machine
is named d.osg.cb.att.uucp (UUCP domain, AT&T company,
Columbus site, Operating System Group project, fourth
machine.) Of course, this example is somewhat verbose and
contrived; it illustrates the heirarchy well, but most
people would rather type something like ``cbosgd.att.uucp''
- 4 -
or even ``cbosgd.uucp'', and actual domains are usually set
up so that you don't have to type very much.
You may wonder why the single @ sign is present, that is,
why the above address does not read
``mark.d.osg.cb.att.uucp''. In fact, it was originally
proposed in this form, and some of the examples in RFC819 do
not contain an @ sign. The @ sign is present because some
ARPANET sites felt the strong need for a divider between the
domain, which names one or more computers, and the left hand
side, which is subject to whatever interpretation the domain
chooses. For example, if the ATT domain chooses to address
people by full name rather than by their login, an address
like ``Mark.Horton@ATT.UUCP'' makes it clear that some
machine in the ATT domain should interpret the string
``Mark.Horton'', but if the address were
``Mark.Horton.ATT.UUCP'', routing software might try to find
a machine named ``Horton'' or ``Mark.Horton''. (By the way,
case is ignored in domains, so that ``ATT.UUCP'' is the same
as ``att.uucp''. To the left of the @ sign, however, a
domain can interpret the text any way it wants; case can be
ignored or it can be significant.)
It is important to note that domains are not routes. Some
people look at the number of !'s in the first example and
the number of .'s in the second, and assume the latter is
being routed from a machine called ``uucp'' to another
called ``att'' to another called ``cb'' and so on. While it
is possible to set up mail routing software to do this, and
indeed in the worst case, even without a reasonable set of
tables, this method will always work, the intent is that
``d.osg.cb.att.uucp'' is the name of a machine, not a path
to get there. In particular, domains are absolute
addresses, while routes depend on the location of the
sender. Some subroutine is charged with figuring out, given
a domain based machine name, what to do with it. In a high
quality environment like the ARPA Internet, it can query a
table or a name server, come up with a 32 bit host number,
and connect you directly to that machine. In the UUCP
environment, we don't have the concept of two processes on
arbitrary machines talking directly, so we forward mail one
hop at a time until it gets to the appropriate destination.
In this case, the subroutine decides if the name represents
the local machine, and if not, decides which of its
neighbors to forward the message to.
- 5 -
2. What is a Domain?
So, after all this background, we still haven't said what a
domain is. The answer (I hope it's been worth the wait) is
that a domain is a subtree of the world tree. For example,
``uucp'' is a top level domain (that is, a subtree of the
``root''.) and represents all names and machines beneath it
in the tree. ``att.uucp'' is a subdomain of ``uucp'',
representing all names, machines, and subdomains beneath
``att'' in the tree. Similarly for ``cb.att.uucp'',
``osg.cb.att.uucp'', and even ``d.osg.cb.att.uucp''
(although ``d.osg.cb.att.uucp'' is a ``leaf'' domain,
representing only the one machine).
A domain has certain properties. The key property is that
it has a ``registry''. That is, the domain has a list of
the names of all immediate subdomains, plus information
about how to get to each one. There is also a contact
person for the domain. This person is responsible for the
domain, keeping the registry up-to-date, serving as a point
of contact for outside queries, and setting policy
requirements for subdomains. Each subdomain can decide who
it will allow to have subdomains, and establish requirements
that all subdomains must meet to be included in the
registry. For example, the ``cb'' domain might require all
subdomains to be physically located in the AT&T building in
Columbus.
ARPA has established certain requirements for top level
domains. These requirements specify that there must be a
list of all subdomains and contact persons for them, a
responsible person who is an authority for the domain (so
that if some site does something bad, it can be made to
stop), a minimum size (to prevent small domains from being
top level), and a pair of nameservers (for redundancy) to
provide a directory-assistance facility. Domains can be
more lax about the requirements they place on their
subdomains, making it harder to be a top level domain than
somewhere lower in the tree. Of course, if you are a
subdomain, your parent is responsible for you.
One requirement that is NOT present is for unique parents.
That is, a machine (or an entire subdomain) need not appear
in only one place in the tree. Thus, ``cb'' might appear
both in the ``att'' domain, and in the ``ohio'' domain.
This allows domains to be structured more flexibly than just
the simple geography used by the postal service and the
telephone company; organizations or topography can be used
in parallel. (Actually, there are a few instances where
this is done in the postal service [overseas military mail]
and the telephone system [prefixes can appear in more than
- 6 -
one area code, e.g. near Washington D.C., and Silicon
Valley].) It also allows domains to split or join up, while
remaining upward compatible with their old addresses.
Do all domains represent specific machines? Not
necessarily. It's pretty obvious that a full path like
``d.cbosg.att.uucp'' refers to exactly one machine. The OSG
domain might decide that ``cbosg.att.uucp'' represents a
particular gateway machine. Or it might decide that it
represents a set of machines, several of which might be
gateways. The ``att.uucp'' domain might decide that several
machines, ``ihnp4.uucp'', ``whgwj.uucp'', and ``hogtw.uucp''
are all entry points into ``att.uucp''. Or it might decide
that it just represents a spot in the name space, not a
machine. For example, there is no machine corresponding to
``arpa'' or ``uucp'', or to the root. Each domain decides
for itself. The naming space and the algorithm for getting
mail from one machine to another are not closely linked -
routing is up to the mail system to figure out, with or
without help from the structure of the names.
The domain syntax does allow explicit routes, in case you
want to exercise a particular route or some gateway is
balking. The syntax is
``@dom1,@dom2,...,@domn:user@domain'', for example,
@ihnp4.UUCP,@ucbvax.UUCP,:joe@NIC.ARPA, forcing it to be
routed through dom1, dom2, ..., domn, and from domn sent to
the final address. This behaves exactly like the UUCP !
routing syntax, although it is somewhat more verbose.
By the way, you've no doubt noticed that some forms of
electronic addresses read from left-to-right (cbosgd!mark),
others read from right-to-left (mark@Berkeley). Which is
better? The real answer here is that it's a religious
issue, and it doesn't make much difference. left-to-right
is probably a bit easier for a computer to deal with because
it can understand something on the left and ignore the
remainder of the address. (While it's almost as easy for
the program to read from right-to-left, the ease of going
from left-to-right was probably in the backs of the minds of
the designers who invented host:user and host!user.)
On the other hand, I claim that user@host is easier for
humans to read, since people tend to start reading from the
left and quit as soon as they recognize the login name of
the person. Also, a mail program that prints a table of
headers may have to truncate the sender's address to make it
fit in a fixed number of columns, and it's probably more
useful to read ``mark@d.osg.a'' than ``ucbvax!sdcsv''.
- 7 -
These are pretty minor issues, after all, humans can adapt
to skip to the end of an address, and programs can truncate
on the left. But the real problem is that if the world
contains BOTH left-to-right and right-to-left syntax, you
have ambiguous addresses like x!y@z to consider. This
single problem turns out to be a killer, and is the best
single reason to try to stamp out one in favor of the other.
3. So why are we doing this, anyway?
The current world is full of lots of interesting kinds of
mail syntax. The old ARPA ``user@host'' is still used on
the ARPANET by many systems. Explicit routing can sometimes
by done with an address like ``user@host2@host1'' which
sends the mail to host1 and lets host1 interpret
``user@host2''. Addresses with more than one @ were made
illegal a few years ago, but many ARPANET hosts depended on
them, and the syntax is still being used. UUCP uses
``h1!h2!h3!user'', requiring the user to route the mail.
Berknets use ``host:user'' and do not allow explicit
routing.
To get mail from one host to another, it had to be routed
through gateways. Thus, the address ``csvax:mark@Berkeley''
from the ARPANET would send the mail to Berkeley, which
would forward it to the Berknet address csvax:mark. To send
mail to the ARPANET from UUCP, an address such as
``ihnp4!ucbvax!sam@foo-unix'' would route it through ihnp4
to ucbvax, which would interpret ``sam@foo-unix'' as an
ARPANET address and pass it along. When the Berknet-UUCP
gateway and Berknet-ARPANET gateway were on different
machines, addresses such as
``csvax:ihnp4!ihnss!warren@Berkeley'' were common.
As you can see, the combination of left-to-right UUCP syntax
and right-to-left ARPANET syntax makes things pretty
complex. Berknets are gone now, but there are lots of
gateways between UUCP and the ARPANET and ARPANET-like mail
networks. Sending mail to an address for which you only
know a path from the ARPANET onto UUCP is even harder -
suppose the address you have is ihnp4!ihnss!warren@Berkeley,
and you are on host rlgvax which uses seismo as an ARPANET
gateway. You must send to
seismo!ihnp4!ihnss!warren@Berkeley, which is not only pretty
hard to read, but when the recipient tries to reply, it will
have no idea where the break in the address between the two
UUCP pieces occurs. An ARPANET site routing across the UUCP
world to somebody's Ethernet using domains locally will have
to send an address something like ``xxx@Berkeley.ARPA'' to
get it to UUCP, then ``ihnp4!decvax!island!yyy'' to get it
- 8 -
to the other ethernet, then ``sam@csvax.ISLAND'' to get it
across their ethernet. The single address would therefore
be ihnp4!decvax!island!sam@csvax.ISLAND@Berkeley.ARPA, which
is too much to ask any person or mailer to understand. It's
even worse: gateways have to deal with ambiguous names like
ihnp4!mark@Berkeley, which can be parsed either
``(ihnp4!mark)@Berkeley'' in accordance with the ARPANET
conventions, or ``ihnp4!(mark@Berkeley)'' as the old UUCP
would.
Another very important reason for using domains is that your
mailing address becomes absolute instead of relative. It
becomes possible to put your electronic address on your
business card or in your signature file without worrying
about writing six different forms and fifteen hosts that
know how to get to yours. It drastically simplifies the job
of the reply command in your mail program, and automatic
reply code in the netnews software.
4. Further Information
For further information, some of the basic ARPANET reference
documents are in order. These can often be found posted to
Usenet, or available nearby. They are all available on the
ARPANET on host NIC via FTP with login ANONYMOUS, if you
have an ARPANET login. They can also be ordered from the
Network Information Center, SRI International, Menlo Park,
California, 94025.
RFC819 The Domain Naming Convention for Internet User Applications
RFC821 Simple Mail Transfer Protocol
RFC822 Standard for the Format of ARPANET Text Messages
RFC881 The Domain Names Plan and Schedule
#
# @(#)domain.mm 2.1 smail 12/14/86
#