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 15:47:45 EDT
From: mondics@tartan.com
I saved this message from the sun-nets mailing list.
I hope it helps.
Brian
>From Sun-Nets-request@umiacs.UMD.EDU Thu Aug 30 12:30:20 1990
>Return-Path: <Sun-Nets-request@umiacs.UMD.EDU>
>Received: from skippy.umiacs.UMD.EDU by tartan.com (4.0/SMI-DDN)
> id AA15596; Thu, 30 Aug 90 12:30:07 EDT
>Received: by skippy.umiacs.UMD.EDU (5.61/UMIACS-0.9/04-05-88)
> id AA16024; Thu, 30 Aug 90 09:54:01 -0400
>In-Reply-To: rhoward@msd.gatech.edu's message of Aug 29, 15:57.
>X-Mailer: Mail User's Shell (7.1.1 5/02/90)
>To: rhoward@msd.gatech.edu, sun-nets@umiacs.umd.edu (Sun-Nets)
>Subject: Re: nres_gethostbyaddr error in /var/adm/messages
>Message-Id: <9008300917.AA13513@aecom.yu.edu>
>Date: 30 Aug 90 09:17:56 EDT (Thu)
>From: uunet!aecom.yu.edu!naftoli@umiacs.UMD.EDU (Robert N. Berlinger)
>Sender: Sun-Nets-request@umiacs.UMD.EDU
>Status: RO
>
>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.1114@compuserve.com
>Albert Einstein College of Medicine |AppleLink: D3913@applelink.apple.com
>
-----------------------------------------------
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)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:59 CDT