Xref: utzoo alt.sys.sun:3221 comp.unix.admin:1377 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!gatech!purdue!haven!mimsy!anagld!rcsmith From: rcsmith@anagld.analytics.com (Ray Smith) Newsgroups: alt.sys.sun,comp.unix.admin Subject: Re: gethostbyaddr: messages on Sun running resolver Keywords: resolver sun4 gethostbyaddr Message-ID: <690@anagld.analytics.com> Date: 22 Mar 91 19:26:59 GMT References: Followup-To: alt.sys.sun Organization: Computer Sciences Corporation - Systems Engineering Division Lines: 318 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. >!= 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: > > syslog: nres_gethostbyaddr: != > > 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" 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" 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 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 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