>ping has this problem if you integrate the bind routines into the
>shared C library - i.e. the problem does not occur with the shared
>library shipped with 4.1.1. (when will Sun learn that not *everyone*
>likes sleeping with NIS).
This remark is a non-sequitur. The "problem" does not occur if you use
the normal libc.so, i.e. the one that references the "hosts" NIS map or
/etc/hosts. Yet you complain "not *everyone* likes sleeping with NIS".
Right after you've noted that the problem is not caused by anything related
to NIS. ?!?
The problem is that the "normal" (non-ISI) `ping' tries to do a gethostbyaddr()
on the address that you are pinging. If the nameserver doesn't respond that
round-trip time gets into the `perceived' ping return time, which can cause
the strange results you posted. I run PPP over a serial link from home, and
I use a libc.so+resolver on that machine, so long round-trip times for DNS
lookups on `ping' addresses frequently cause me to see the same symptoms you
have. If you really want to "fix" this problem, have Berkeley (or whomever)
change their "ping" so that it has an option to disable the inverse lookup.
Now, up on my soapbox:
As for "when will Sun learn ...", I do not think I should even have to defend
myself against that statement. Most of our customers are not on the Internet,
so to default to a resolver-using libc.so would be madness. Starting with
SunOS 4.1, we provided the means to build your own customized libc.so via the
"Shlib Custom" optional software category, and as soon as I received 4.1, I
set about making a Priority 1 task of building a libc.so with the resolver
routines, and providing a version of the /usr/lib/shlib.etc/README file that
contained the instructions on how to do so, in an easy to follow format. I'd
say it's a safe bet that a good percentage of the readership of this mailing
list have reaped the benefits of this effort. I tried to get it into 4.1.1 and
submitted an RFE, but I just missed the cutoff date. It bothers me to have
made the effort to help out our Internet customers, yet on this (and Sun-Nets
as well as other newsgroups) I still keep seeing derogatory comments like
"Sun is definitely not in a big hurry to use DNS. I HIGHLY recommend against
using Sun's DNS" - and I begin to wonder if it's worth it. We have an
extremely capable Internet Engineering manager whom I have a lot of respect
for, and we still have some crack Engineering talent in that area.
Disclaimer: yes, it's been a long work week. And yes, although I work for
Sun, these are not the official views of Sun Microsystems, Inc. by any stretch
of the imagination. They are the views of one Sun employee who tries his best
to help out, yet still sees us getting endlessly flamed about DNS issues.
End of disclaimer.
-- - Greg Earle Sun Microsystems, Los Angeles - JPL on-site Software Support earle@poseur.JPL.NASA.GOV earle@Sun.COM
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:09 CDT