See an unfamiliar term? Check the newsletter glossary.
News from:
M V C o m m u n i c a t i o n s , I n c .
P.O. Box 4963
Manchester, NH 03108-4963
(603) 429-2223
October 1992
Note: text copies of all issues of the monthly newsletter can be found
on mv in the public archive; look in /news2/pub/mv/inews.
Subdomaining your MV.COM address
For those of you in our .MV.COM domain park, we've recently made
it possible for your site name to double as a subdomain name as well
as a primary Internet address. For an example, consider the site
"zinn.mv.com", which represents Zinn Computer Company and has a con-
nection to mv with membership in the MV.COM domain. Zinn may want to
add another machine "moby", and have it treated as part of the primary
"zinn.mv.com" address. Using zinn.mv.com as a subdomain, moby could
be connected to zinn (e.g. via UUCP or local ethernet) and addressed
from the outside world as "moby.zinn.mv.com".
In this case, mail addressed to "duck@zinn.mv.com" would be han-
dled as before. That is, it would be queued from mv to zinn, to be
processed by zinn's rmail command with an address of "duck". Mail to
a subdomain address, e.g. "robin@moby.zinn.mv.com", will be queued
from mv to zinn, again to be processed by zinn's rmail command, but
with a full address of "moby.zinn.mv.com!robin". To make use of this
facility, it will be up to zinn to recognize and properly handle the
second kind of address. This can be done fairly easily by smart
mailers such as smail or sendmail.
Subdomaining in this fashion allows you to have any number of
machines tied into your .MV.COM domain address with a valid Internet
mail address rather than via explicit UUCP routing. Those subdomain
sites should properly be machines within your own organization.
Why Domains in the First Place?
The subject of subdomaining .MV.COM addresses prompts us to
reprint some comments we've made earlier about domains and how mail is
routed at MV. This question comes up occasionally, and as more people
are introduced to the network, it's important to bring it up from time
to time.
You need a real, fully qualified domain name (sometimes called an
FQDN) to receive mail reliably from the Internet, but you may not know
MV Communications, Inc. October 1992
- 2 -
why this is so. Behind this is the notion of the "fully connected
Internet," which is the set of sites that are constantly connected to
each other by dedicated links of some sort, and between which packets
of information can be sent and received at any moment. Sites on this
Internet address each other by their Internet Protocol number, or IP
number. For the purposes of Internet mail, each fully qualified
domain name translates into the IP address of one of these sites, or
to the address of a site that knows how to deliver mail to its desti-
nation. (The latter is an important point: it's why you don't need a
constantly connected Internet link to have a legitimate Internet mail
address. All you need is a site on the Internet that takes responsi-
bility for your address.) The domain system implements a hierarchical
system of namespace management to facilitate this translation from a
FQDN to the IP address of a responsible Internet site. The key point
to this namespace is that it is arranged in a rooted hierarchy,
spreading the control of namespaces to the most appropriate, local
place.
This namespace hierarchy is managed through a distributed system
of nameservers. Each domain's namespace is managed by two or more
nameservers: one primary and one or more secondaries. (The secon-
daries load their information periodically from the primary, and can
provide name lookup if the primary is unreachable.) Nameserver data-
bases can contain many things, but for the purposes of mail delivery
to sites, the significant entries are host (IP) addresses, addresses
of sites that can forward to the destination site or domain, and
addresses of nameservers for subordinate domains.
When an Internet site sends mail to a recipient with a valid
Internet domain address, it uses this distributed nameservice to
translate the destination site's fully qualified domain name to an IP
address (or a forwarder address). A "root" nameserver is consulted to
find the appropriate nameserver within the specific top level domain.
That second nameserver is consulted to translate the next lowest (more
specific) name, and so forth until a site resolution has occurred. If
an address can not be resolved by an entry in the Internet nameserver
mechanism, the mail can not be delivered. There's nowhere to send it!
The distributed nameserver system facilitates low-level domain
registration. To register within a domain, it is only necessary to
update the name server for that domain. So to add a new entry in a
top level domain, e.g. "COM" or "EDU" or "MIL", the entry must be made
with the root nameservers. New entries within a top-level domain can
only be domains themselves, and require configuration of primary and
secondary nameservers. This involves a lot of overhead and bureau-
cracy, and can take some time. However, to add an entry within an
existing domain, registration only need occur within that domain.
Only the local authority is involved. This is why, for example,
registering a site in the MV.COM domain only takes overnight, whereas
registering a new top-level domain can take a month or more.
From this, it's evident that the use of a well-formed, legitimate
Internet mail address results in more reliable mail than using an
explicit route as with UUCP mail paths. Mail with a domain-style
MV Communications, Inc. October 1992
- 3 -
address can be delivered to a responsible site almost immediately.
Furthermore, since the authority for namespace rests with the most
local level, and usually with people who are charged with its care,
domain-form namespace is nearly always up to date. Contrast this with
UUCP-style or other explicit route forms, which are based on snapshots
of global mapping information that is almost always wrong. This is
not to say that things can not go wrong with Internet mail: they can,
and sometimes do -- usually when the most local level of administra-
tion is still fairly large.
Miscellany
* Please note that if you want to add more MV connections or know
of others that want to connect, running Unix is not a requirement
for uucp access. MV currently has several clients running PCs
and MACs, using uupc, waffle, fernmail, and other uucp-like pack-
ages for these systems. And the software for several of these
packages is available in the public archive.
* If you recommend MV to someone, make sure they tell us about you
too! We'll credit a referral fee to your account of half the new
monthly fee.
* MV maintains an archive of files related to UUCP and networking,
and of files of recent interest. This archive is in /news2/pub
on mv; a directory (updated nightly) is in the file
/news2/pub/ls-lR, with a compressed version of
/news2/pub/ls-lR.Z.
* Remember that the official modem telephone number for all of our
modems is 603-429-1735. This will give you access to all of the
lines in the hunt group.
MV Communications, Inc. October 1992