Xref: utzoo alt.sys.sun:3220 comp.unix.admin:1373 Path: utzoo!utgpu!cs.utexas.edu!samsung!caen!stealth From: stealth@caen.engin.umich.edu (Mike Pelletier) Newsgroups: alt.sys.sun,comp.unix.admin Subject: Re: gethostbyaddr: messages on Sun running resolver Keywords: resolver sun4 gethostbyaddr Message-ID: <1991Mar22.161040.9722@engin.umich.edu> Date: 22 Mar 91 16:10:40 GMT References: Sender: news@engin.umich.edu (CAEN Netnews) Organization: University of Michigan Engineering, Ann Arbor Lines: 31 In article cornell@csl.dl.nec.com (Cornell Kinderknecht) writes: > >I'm running resolver libraries on a Sun server. When I get mail from >some sites or a telnet is done from some sites, I get a message similar >to the following at the console. > gethostbyaddr: != >Where is the abc.abc.abc.abc name >and is the 123.123.123.123 ip number. I've gotten a similar problem from certain sites on a telnet service I've been running on my Sun SparcStation... >!= implies not equal however the ip number and host name that are given >are indeed the correct corresponding ipnumber and hostname (they are >resolved correctly when you get ipnumber from hostname). This puzzled me as well... I managed to find out that the error results from the following process: gethostbyaddr takes the IP address of the incoming connection, say it's 35.1.2.3, and does a reverse lookup for it to get a hostname. It then takes the hostname it got and does a forward lookup to get an IP address. If the IP address returned by the lookup and the IP address of the connection don't match, it logs the above error and drops the connection. This could result from an incorrect entry in the nameservice database, dynamically allocated addresses, and particularly, spoofed connections, which is what this process is trying to weed out. I don't know of any way to get around it aside from not calling gethostbyaddr(), does anyone else have suggestions?