LOCALHOST.NET, LOCALHOST.COM, etc.

["L. Stuart Vance" <[e-mail]>]

Bleah.  I say again, bleah.  Comments on the message below would be
appreciated.  LOCALHOST.NET is not _too_ much of a problem now, but I can
imagine that when the folks at LOCALHOST.COM start advertising an A record,
things could get really ugly really quickly.  This turns out to be a badly
degenerate case of problems that Ehud Gavron raised in RFC 1535.

Thoughts?

Regards!
-----Stuart

Date: Mon, 17 Jun 1996 07:05:10 -0700 (PDT)
From: [e-mail] (L. Stuart Vance)
Subject: Problem with LOCALHOST
To: [e-mail]
Message-id: <[e-mail]>
Organization: Cisco Systems, Inc.
Content-transfer-encoding: 7BIT
Mail-system-version: <MultiNet-MM(380)+TOPSLIB(158)@tgv.com>
X-Address: 101 Cooper Street; Santa Cruz, CA  95060 (work)
X-Phone: [phone] (work); [phone] (fax)

We've stumbled across an interesting problem, and wanted to spread the word far
and wide before someone gets badly bitten by it.

A company has registered the domain LOCALHOST.NET, and is now serving out a
"A", or address, record for the name LOCALHOST.NET.  This can cause problems for
you if your site meets the following criteria:

o Your domain name is in the .NET domain

o You have assigned a host the same hostname as your domain name (i.e., your
  domain is FOO.NET, and you assign the name FOO.NET to a particular host)

o You do not have a local domain defined (specified with the NET-CONFIG command
  SET LOCAL-DOMAIN and the logical name MULTINET_LOCALDOMAIN)

o You do *NOT* have an A record in your DNS configuration for (continuing the
  example above) LOCALHOST.FOO.NET

If a host at your site meets all of the above criteria, then if you issue the
command:

$ TELNET LOCALHOST

you will be connected with the host LOCALHOST.NET rather than your local
system.

We have been investigating this problem, and there is no general fix that we
can make to MultiNet to correctly fix this problem in all situations
world-wide.  While we are RFC1535 compliant for how we handle domain searches
in our resolver code, RFC1535 states (paraphrased) that one should
only perform a search in the "parent domain".  For FOO.NET, the "parent"
domain would be ".NET".  For FOO.CO.AU, the parent domain would be ".CO.AU".

There are several workarounds to this problem.  The "top two" are:

o Do not assign your domain name to be the name of any host.  You can still
  create an address record for the domain name pointing at your host (so that
  people can still FTP to FOO.NET), but assign the host some other name.

o Add an address record to your DNS configuration for LOCALHOST.FOO.NET.

Note that this problem is inherent in BIND's resolver code, and is NOT specific
to MultiNet.

Note also that another company has registered the domain LOCALHOST.COM, but has
not (thank goodness) started serving out an A record for it.

If you have any questions, please feel free to drop me a note.

Regards!
-----Stuart