cornell@csl.dl.nec.com (Cornell Kinderknecht) (03/17/91)
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: <host.name> != <ip.addr> Where <host.name> is the abc.abc.abc.abc name and <ip.addr> is the 123.123.123.123 ip number. != 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). Does anyone know what I can do to either 1) correct this or 2) suppress the message? Cornell Kinderknecht cornell@csl.dl.nec.com
stealth@caen.engin.umich.edu (Mike Pelletier) (03/23/91)
In article <cornell.669203150@texas> 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: <host.name> != <ip.addr> >Where <host.name> is the abc.abc.abc.abc name >and <ip.addr> 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?
rcsmith@anagld.analytics.com (Ray Smith) (03/23/91)
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: <host.name> != <ip.addr> >Where <host.name> is the abc.abc.abc.abc name >and <ip.addr> is the 123.123.123.123 ip number. >!= 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). >Does anyone know what I can do to either 1) correct this or 2) suppress >the message? >Cornell Kinderknecht >cornell@csl.dl.nec.com Don't know if this is what your problem is by here are some things that I archived a while back regarding gethostbyaddr. Hope it helps, Ray ----------------------- BEGIN INCLUDED MESSAGES ----------------------- Subject: Re: nres_gethostbyaddr error in /var/adm/messages Date: 30 Aug 90 09:17:56 EDT (Thu) From: uunet!aecom.yu.edu!naftoli (Robert N. Berlinger) On Aug 29, 15:57, rhoward@msd.gatech.edu wrote: > To: sun-nets@umiacs.umd.edu (Sun-Nets) > Subject: nres_gethostbyaddr error in /var/adm/messages > > I'm getting some weird messages in my /var/adm/messages file. They > read: > > <hostname> syslog: nres_gethostbyaddr: <some.long.hostname> != <some.IP.num> > > for a number of hosts. > > SS1+ le0 and le1 > OS: 4.1 > Running NIS (yp) > NIS databases built with -b option. > > What does this mean? I haven't been having problems contacting these > machines. What is the nature of the message? >-- End of excerpt from rhoward@msd.gatech.edu Apparently it's a bug in ypserv. Here is information that Sun sent to me about the problem. >From lmc@Sun.COM Thu Aug 9 10:47:32 1990 The following is information on the nres_gethostbyaddr error messages: -Lorraine McLane (415) 336-5214 e-mail - lmc@sun.com 1039839: Synopsis: nres_gethostbyaddr logs misleading messages to console 1039839: Description: 1039839: When using DNS in conjunction with NIS, customer sees 1039839: messages logged to the console like : 1039839: 1039839: nres_gethostbyaddr: xxx.yyy.zzz != aaa.bbb.ccc.ddd 1039839: Where xxx.yyy.zzz is the fully qualified hostname, and 1039839: aaa.bbb.ccc.ddd is the CORRECT IP address for xxx.yyy.zzz 1039839: 1039839: Setup configuration has been verified with nslookup by 1039839: doing a qtype=any, and doing 1039839: > ddd.ccc.bbb.aaa.in-addr.arpa 1039839: 1039839: What's more, is that the syslog level for this message 1039839: is at LOG_CRIT (critical). This should probably be a 1039839: syslog level of no higher than LOG_NOTICE 1039839: 1039839: crit For warnings about critical conditions, such as 1039839: hard device errors. 1039839: 1039839: notice For conditions that are not error conditions, but 1039839: may require special handling. 1039839: Work around: 1039839: Ignore the messages, since they're not really errors, or 1039839: turn off logging of critical error messages. 1039839: Suggested fix: 1039839: Change LOG_CRIT to LOG_NOTICE in nres_gethostbyaddr(), 1039839: else make everything compiled with -lnres have a secure 1039839: or debug option with hooks into the nres_gethostbyaddr 1039839: routine of asynch_resolver/ngethostbyname.c to enable or 1039839: disable these messages. 1039839: Leave it up to the network administrators to decide 1039839: whether or not these are critical errors. 1039839:This problem appear to be in the way YPserv's use of the resolver routines 1039839:interact with the nameserver routines, as it is not duplicatable with 1039839:other resolver based utilities. I suspect a timing problem since the 1039839:address does in fact match the hostname in all reported cases. 1039839: Public Summary: 1039839: DNS used in conjunction with NIS may generate syslog messages 1039839: to the console something like : 1039839: nres_gethostbyaddr: some.name.org != its.correct.IP.addr -- Robert N. Berlinger |Domain: naftoli@aecom.yu.edu Supervisor of Systems Support |UUCP: ...uunet!aecom!naftoli Scientific Computing Center |CompuServe: 76067.1094@compuserve.com Albert Einstein College of Medicine |AppleLink: D3913@applelink.apple.com ------------------------------------------------------ NEXT MESSAGE ------------------------------------------------------ Date: Thu, 30 Aug 90 10:10:59 PDT From: uunet!srv.PacBell.COM!david (David St. Pierre) Subject: Re: nres_gethostbyaddr error in /var/adm/messages On Aug 30, 9:17am, Robert N. Berlinger wrote: REPEATED MESSAGE DELETED TO SAVE SPACE I think I filed this problem with Sun a few months ago. Initially, I (probably naively) agreed that they shouldn't be CRIT errors. But to suggest that one *ignore* critical errors isn't very good advice. (And if they fixed the bug it probably *should* be a critical error.) This problem shows up for in-bound ftp, UUCP over TCP/IP. It doesn't seem to happen for in-bound telnet. I suspect that most people would link nntp with the -lresolv libraries. It shows up in traceroute, netstat -r, etc. if the host entry isn't local. The problem seems to go away if the in-addr entry is currently in the cache. If the local name server has to send the query out to another name server, the problem seems to show up. Personally, I find this problem awfully annoying. I got Sun to ship me a copy of ftpd linked with -lresolv and the problems for that program went away. I wish they would get this one fixed and a patch sent out!!! -- David St. Pierre 415/823-6800 {att,bellcore,sun,ames,decwrl}!pacbell!david ------------------------------------------------------ NEXT MESSAGE ------------------------------------------------------ From: "Leonardo C. Topa" <uunet!ai.mit.edu!leo> Date: Fri, 26 Oct 90 10:35:35 EDT Subject: SUMMARY: problems with nres_gethostbyaddr Some time ago I asked: Date: Wed, 10 Oct 90 12:20:50 EDT Subject: problems with nres_gethostbyaddr Someone brought this up some time ago, but I think that the suggested fix doesn't work. On a sun 3/280 running 4.1 I keep getting the following messages: Oct 9 14:10:40 hippocampus syslog: nres_gethostbyaddr: ramon.bio.columbia.edu != 128.59.128.2 Oct 9 16:01:30 hippocampus syslog: nres_gethostbyaddr: WCCF.MIT.EDU!= 18.88.0.128 Oct 9 17:00:44 hippocampus syslog: nres_gethostbyaddr: E40-008-6.MIT.EDU != 18.71.0.18 Oct 9 17:38:50 hippocampus syslog: nres_gethostbyaddr: NEANDERTHAL.MIT.EDU != 18.88.0.88 Oct 9 18:34:20 hippocampus syslog: nres_gethostbyaddr: OSLER.MIT.EDU != 18.88.0.46 Oct 9 22:48:57 hippocampus syslog: nres_gethostbyaddr: Chuckles.Think.COM != 131.239.53.145 Oct 9 23:40:40 hippocampus syslog: nres_gethostbyaddr: gargoyle.uchicago.edu != 128.135.20.100 I thought the fix is to have the "-l" flag in the Makefile that creates the hosts.byname yellow page map, but this doesn't seem to cure the problem. Please answer to me directly and I'll summarize. -Leonardo Topa A little overdue, but here is the summary of what I found. Devid St. Pierre says there is now a patch available from Sun for this, but I cannot check because right now our campus network is having problems with outside hosts. Is sun.com the hostname to check? ----------------------------------------------- Date: Fri, 19 Oct 90 11:59:21 PDT From: "David St. Pierre" <david@srv.pacbell.com> I was just looking at Sun's online bugs data base today and noticed that the 4.1 problem with syslog reporting spurious "errors" now has a patch available. The patch was dated 15 Oct. ----------------------------------------------- Other answers were: ----------------------------------------------- Date: Wed, 10 Oct 90 12:49:46 -0600 From: Jeff Nieusma <nieusma@eclipse.colorado.edu> there is no reason for you to get the messages: Name: ramon.bio.columbia.edu Address: 128.59.128.2 2.128.59.128.in-addr.arpa host name = ramon.bio.columbia.edu Name: WCCF.MIT.EDU Address: 18.88.0.128 128.0.88.18.IN-ADDR.ARPA host name = WCCF.MIT.EDU Name: E40-008-6.MIT.EDU Address: 18.71.0.18 18.0.71.18.IN-ADDR.ARPA host name = E40-008-6.MIT.EDU [...] I can't offer a fix for you since we aren't using NIS anymore. I just removed NIS and am using libc.so with the resolver built in. ^^^^^^^^^^^^^^^^^^^^^^^^^^ (how do you do that? -LCT) ----------------------------------------------- Date: Wed, 10 Oct 90 11:54:56 PDT From: mike@inti.lbl.gov (Michael Helm) A recompiled ypserv (with the noisy log messages set to a different syslog priority) does the trick. If you have source I think I can arrange to send you the patches; if you don't maybe we can work something out for the binary. Luck, ==mwh ----------------------------------------------- Date: Wed, 10 Oct 90 21:16:18 -0400 From: henryc@oar.net In article <9010101620.AA00805@vivaldi> you write: >Someone brought this up some time ago, but I think that the suggested >fix doesn't work. On a sun 3/280 running 4.1 I keep getting the >following messages: >Oct 9 23:40:40 hippocampus syslog: nres_gethostbyaddr: gargoyle.uchicago.edu != 128.135.20.100 Some would view them as a feature of 4.1. Bend over and smile. Don't worry about them, really! Henry henryc@oar.net ----------------------------------------------- The following people asked that I let them know if I find a fix: bauer%cns.UCalgary.CA@ucnet.ucalgary.ca casper@fwi.uva.nl (Casper H.S. Dik) eap@bu-pub.bu.edu (Eric A Pearce) ------------------------------------------------------- NEXT MESSAGE ------------------------------------------------------- Archived date: 901108 Y90 M11 D08 From: Mike Jipping <uunet!frodo.cs.hope.edu!jipping> Date: Wed, 7 Nov 1990 06:44:09 EST Subject: "nres_gethostbyaddr !=" errors SOLVED! Ever since upgrading to SunOS 4.1, we have been inundated with messages on the console of our Internet gateway machine like nres_gethostbyaddr: some.name.org != its.correct.IP.addr Judging by the traffic on sun-managers, others have hit on this and have gone crazy trying to get rid of them. About a week ago, I received a patch from Sun to fix this. There is no REAL problem, the messages are erroneous. The fix is a new "ypserv" program. I have included a snippet from the README file below after the signature. These patches are available on smaug.cs.hope.edu (35.197.146.1) in ~ftp/pub as -rw-r--r-- 1 root 39626 Nov 7 06:37 nres_patch_sun3.tar.Z -rw-r--r-- 1 root 47160 Nov 7 06:37 nres_patch_sun4.tar.Z Each file contains the README file and an architecture-specific patch. We've been running this for about a week with no new messages. Hope others find this useful. Mike Jipping Hope College Department of Computer Science jipping@cs.hope.edu (BITNET: JIPPING@HOPE) "Anatidaephobia: The fear that somewhere, somehow, a duck is watching you." -- Gary Larson ================================================================== Patch-ID# 100141-01 Keywords: NIS DNS nres_gethostbyaddr messages console Synopsis: nres_gethostbyaddr logs misleading messages to console Date: 15-Oct-90 SunOS release: 4.1 Unbundled Product: Unbundled Release: BugId's fixed with this patch: 1039839 Architectures for which this patch is available: sun3, sun4 Obsoleted by: Problem Description: DNS used in conjunction with NIS may generate syslog messages to the console something like : nres_gethostbyaddr: some.name.org != its.correct.IP.addr -- Ray Smith Computer Sciences Corporation - Systems Engineering Division Formerly Analytics, Inc. rcsmith@analytics.com -or- {uunet,aplcen,wb3ffv,sundc}!anagld!rcsmith -or- RCSmith@DOCKMASTER.NCSC.MIL