Coming to closure on athena.dialup.mit.edu
DCNS needs to decide what solution to take in the long-term to continue
to allow authenticated telnet to athena.dialup.mit.edu.
- nameserver solution
- dialup server solution
- client solution
1. nameserver solution
Summary of drawbacks:
- Increased load on DIALUP.MIT.EDU name service
- User may have to retry telnet more often (but still rarely)
- Development time involved in understanding, changing and testing the
load-balancing named
When the nameservers finch.mit.edu and theseus.mit.edu receive a query
for the internet address of athena.dialup.mit.edu, they return an A
record with four addresses. These addresses are for the four "best"
dialup hosts to connect to. A smart telnet client will try each address
until it successfully connects. The canonical name for each address is
athena.dialup.mit.edu.
For the canonical name to be more specific, e.g. alfredo.mit.edu, the
nameserver must treat athena.dialup.mit.edu as a cname. This means that
only one address can be returned. If this address corresponds to a host
that has become unavailable since the nameserver first decided it was
the best dialup host (e.g. it crashes), then telnet clients will exit
with an error message. The user then has to try again.
When the user tries again, a different dialup host should be suggested.
This necessitates a short expiration time (5 sec?) for the result of the
nameserver query. We don't have hard data (as of 9/6/94) regarding the
impact of increased load on the nameservers.
Tom Coppetto <tom@mit.edu> says:
increased load on the dialup nameserver is not a concern. The MIT
nameservers process orders of magnitude more queries without
breathing hard. Most of these clients (pc's) do not cache results.
The dialup nameserver traffic is a drop in the bucket.
2. dialup server solution
Summary of drawbacks:
- additional step in process of setting up a dialup server
- must maintain customization of telnetd
Note: Only telnet to the dialups uses shared keys among
all the servers. Telnet is configured on the dialups to ask for a
password in addition to kerberos authentication. Therefore a cracker
gains nothing by compromising the shared keys. Only the first key in
the srvtab (e.g. rcmd.alfredo) can be used to rlogin without a password.
This applies to all accounts, including root. For this reason, it may
never be necessary to update the rcmd.athena service keys, etc.
3. client solution
Summary of drawbacks:
- need to change source code for all supported clients
- unsupported clients may never do it
- DNS in both directions may produce undesired results (e.g. w20-rtr.mit.edu)
Bruce R. Lewis / <brlewis@mit.edu>
$Date: 94/09/07 11:54:58 $