[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Domains, aliases and namesolvers
From:       mills () dcn6
Date:       1984-12-13 5:19:32
[Download RAW message or body]

Folks,

The purpose of this note is to expose certain issues in the transition from
the traditional host name/address translation mechanism, usually done with the
aid of host-resident tables, and the new RFC-882/3 system based on the use of
domain host-name resolvers (henceforth: namesolvers). We are overhauling the
SMTP and MPM mail systems for our LSI-11 "fuzzballs" to incorporate the new
system while, at the same time, removing encrusted "temporary" .ARPA-suffix
spells and other witchcraft in the message-composition and message-answer
areas.

Most of the spells have to do with the .ARPA domain suffix and aliases in the
NIC table (HOSTS.TXT), which is copied and used by the fuzzies (and many other
systems) to drive the existing host name/address translation mechanism. The
ARPA suffix has been added to what formerly was the principal name for each
host and now forms the principal name, with the former name as an alias. Our
message-composition programs for both SMTP and MPM have been changed so that
only names appearing in HOSTS.TXT are allowed; in particular, the .ARPA suffix
is NOT allowed for aliases.

A little experimentation reveals that the ISI TOPS-20s operate the same way,
at least for SMTP mail, but some 4.2 Unix systems DO allow the suffix for
aliases and include it in transmitted message at both the mail and SMTP
headers, even if not in HOSTS.TXT. Interestingly, the ISI TOPS-20s behave like
the 4.2s for MPM mail, but this could be for other reasons (see below).

Mail arriving at a fuzzball is presently rejected unless the destination host
name appears as-is in HOSTS.TXT. This works fine in the case of principal
names with or without the .ARPA suffix, but works in the case of aliases only
if the names do not have the suffix. The TOPS-20s and 4.2s, which take a more
liberal approach, do accept aliases with and without the suffix. This is
probably a more reasonable thing to do, at least for the near future. In the
TOPS-20 and 4.2 case the message appears in the user's mailbox exactly as
sent, suffixes and all.

When replying to a message containing an alias with the suffix, the fuzzies
croak on an invalid host name as you might expect. TOPS-20 carefully
transforms all such names to the principal names before duplicate removal,
which is probably the more reasonable thing to do. With 4.2, this
transformation is not done, although the suffix is not inserted in the reply.
The only problem with this is that duplicates due to aliases mapping to
the same principal name are not caught. 

Now enter the namesolver, which issue prompted this message in the first
place. It appears that the homeless aliases in HOSTS.TXT have found homes in
the ARPA domain, which appears to be a wholly reasonable thing to do. But,
now the old name server and new namesolver operate differently, in that the
ARPA suffix is now valid everywhere. We found some pretty exotic behavior
during mail-forwarding experiments due to this cause.

I gather from these observations that the fuzzies should go back to school and
learn to behave like the TOPS-20 model. I also firmly support Jon Postel's
oft-stated plea that aliases be mapped to principal names BEFORE mail escapes
outside the host. I also argue that, for consistency the HOSTS.TXT table
should include an explicit .ARPA suffix for every entry, including the
aliases. This will become necessary in any case when the .DDN suffix is
activated.

Every time I ponder these things my brain overheats, since so many issues are
involved. Hopefully, our blundering may reduce the entropy and lesson the
grief during the transition.

Dave
-------

[prev in list] [next in list] [prev in thread] [next in thread]