gethostbyaddr: messages on Sun running resolver
Ray Smith
rcsmith at anagld.analytics.com
Sat Mar 23 05:26:59 AEST 1991
cornell at 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 at 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 at msd.gatech.edu wrote:
> To: sun-nets at 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 at msd.gatech.edu
Apparently it's a bug in ypserv. Here is information that Sun sent to me
about the problem.
>From lmc at 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 at 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 at aecom.yu.edu
Supervisor of Systems Support |UUCP: ...uunet!aecom!naftoli
Scientific Computing Center |CompuServe: 76067.1094 at compuserve.com
Albert Einstein College of Medicine |AppleLink: D3913 at 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 at 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 at 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 at 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 at oar.net
In article <9010101620.AA00805 at 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 at oar.net
-----------------------------------------------
The following people asked that I let them know if I find a fix:
bauer%cns.UCalgary.CA at ucnet.ucalgary.ca
casper at fwi.uva.nl (Casper H.S. Dik)
eap at 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 at cs.hope.edu (BITNET: JIPPING at 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 at analytics.com -or- {uunet,aplcen,wb3ffv,sundc}!anagld!rcsmith -or-
RCSmith at DOCKMASTER.NCSC.MIL
More information about the Comp.unix.admin
mailing list