RFC 1681 (rfc1681) - Page 2 of 5
On Many Addresses per Host
Alternative Format: Original Text Document
RFC 1681 On Many Addresses per Host August 1994
Security is another reason, in some cases. Address-based
authentication is bad enough; relying on the name service adds
another layer of risk. An attacker can go after the DNS, in that
case. A risk-averse system manager might prefer to avoid the extra
exposure, instead granting privileges (i.e., rlogin or NFS) by
address instead of name. But that, of course, leads to all the usual
headaches when the location of the service changes. If the address
for the service could be held constant, there would be much more
freedom to move it to another machine. One way to do that is by
assigning the serving host a secondary address.
A related notion comes from the need to offer different views of a
service from a single host. For example, research.att.com has long
offered two distinct FTP archives, with slightly different access
policies. It would be nice if both could live on the same machine,
without asking the user community to learn new protocols or custom
port numbers.
Archie is an even better example. There are three principal ways to
use Archie: use a special protocol, and hence a special application
program, on a dedicated port and host that is probably named
archie.foo.bar; telnet to archie.foo.bar and go through an extra and
gratuitous login as archie, or telnet to some special port on
archie.foo.bar. The latter two are examples of using a standard
protocol (telnet) to offer a different service. Neither alternative
is very convenient.
It would be better if archie.foo.bar provided the Archie service,
while host.foo.bar provided a login prompt. Again -- an easy way to
do this is to assign the host a separate IP address for its extra
service.
Note that there are security advantages here, too. A firewall could
be configured to allow access to the address associated with the
Archie server, but not the other addresses on that host. That would
provide a high degree of safety, assuming, of course, that the other
servers on that host were bound to its primary addresses, and not the
exposed address.
Another way to implement this concept would be to extend the DNS, to
return port number information as well as IP addresses. Thus,
netlib.att.com might return 192.20.225.3/221. But that would
necessitate changing every FTP client program, a daunting task.
We could also look on this as the extension of the MX concept. MX
records are very valuable, but they apply only to mail, and they
don't supply port numbers. Again, changing this would require
massive client program changes.
Bellovin