home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!stanford.edu!agate!spool.mu.edu!decwrl!pa.dec.com!datum.nyo.dec.com!nntpd.lkg.dec.com!MyTH
- From: MyTH@ucx.lkg.dec.com (M. T. Hollinger)
- Newsgroups: vmsnet.networks.tcp-ip.ucx
- Subject: Re: Host: IP is not Host: DOMAIN.NAM. Why?
- Keywords: IP domain
- Message-ID: <1992Nov10.032602.25214@nntpd.lkg.dec.com>
- Date: 10 Nov 92 03:26:02 GMT
- References: <1dn5qqINNmth@crcnis1.unl.edu>
- Sender: usenet@nntpd.lkg.dec.com (USENET News System)
- Reply-To: MyTH@ucx.lkg.dec.com (M. T. Hollinger)
- Organization: Digital Equipment Corporation
- Lines: 26
- Originator: MyTH@hageln.ucx.lkg.dec.com
-
-
- In article <1dn5qqINNmth@crcnis1.unl.edu>, Russell Mosemann writes:
- > We are running UCX 1.3. When I do a show users/full, it displays
- > some of the Host:'s with IP numbers instead of host and domain name.
- > Why? When I get into UCX and do a SHOW HOSTNM IP, it returns the domain
- > name just fine, so it can find it.
-
- From these symptoms I would guess that the reverse hostname translation
- is simply taking a long time to complete. UCX attempts to determine the
- hostname for a connection before acting on it (in this case, presenting
- a login prompt). If the network or the nameservers are slow, the lookup
- can take a long time. Rather than keep the user waiting, UCX times out
- and records the numeric address.
-
- When you later query your local nameserver with the SHOW HOST command,
- it still has the translation in its cache from the aborted attempt at
- hostname lookup before login. Therefore, the command completes right
- away. However, the system does not retry the resolution for the
- now-already-established session, and so the numeric address remains
- for the duration.
-
- Partly for this reason, the default behavior under V2.0 is to not even
- attempt address-to-name translation. At least that way, the remote
- host identification is always shown consistently (as an IP address).
-
- - MyTH
-