Broken Resolver?

Broken Resolver?

Post by System Admin (Mike Peters » Sat, 20 Nov 1993 07:19:24




>I have several machines running a variety of SVR4 OSs and I'm having a
>weird problem with the resolver.

>Our Intel based machines running vanilla SVR4.0 can resolve some
>Internet addresses, but not others.  For instance, our primary host
>cannot ping spacelink.msfc.nasa.gov.

>Here's what happens:

>$ ping spacelink.msfc.nasa.gov
>ping: unknown host spacelink.msfc.nasa.gov

>Same thing when I try to telnet.

>But here's what happens when I do a nslookup:
>Server:  ns.UU.NET
>Address:  137.39.1.3

>Non-authoritative answer:
>Name:    spacelink.msfc.nasa.gov
>Address:  192.149.89.61

We saw basically the same flaky behaviour on our HP-UX 9.01 systems
(which would sometimes/often fail to resolve names, and nslookup
would fail with a "FORMAT ERROR"), but everything would work fine
from an Apollo Domain/OS system (both were named masters, running
named 4.8.3 + patches for $INCLUDE to work properly).
This would also cause bounced mail to perfectly valid sites.

The problems have been totally eliminated by installing named 4.9,
which includes its own resolver routines, so I can't tell whether it
is named 4.8.3 that was defective (though there are lots of bug
fixes in 4.9), or the resolver routines in the system libraries.

I got named 4.9 from gatekeeper.dec.com (in /pub/BSD/bind/4.9);
it is not configured for HP-UX, but I'll pass along what I did
to any interested parties.
--
Work is the slow, dragging fingernail              |  Mike Peterson, SysAdmin
 on the blackboard of life.                        |  U/Toronto Chemistry

 
 
 

Broken Resolver?

Post by Tom Man » Sat, 20 Nov 1993 01:44:34


Hi SVR4 Gurus,

I have several machines running a variety of SVR4 OSs and I'm having a
weird problem with the resolver.

Our Intel based machines running vanilla SVR4.0 can resolve some
Internet addresses, but not others.  For instance, our primary host
cannot ping spacelink.msfc.nasa.gov.

Here's what happens:

$ ping spacelink.msfc.nasa.gov
ping: unknown host spacelink.msfc.nasa.gov

Same thing when I try to telnet.

But here's what happens when I do a nslookup:
Server:  ns.UU.NET
Address:  137.39.1.3

Non-authoritative answer:
Name:    spacelink.msfc.nasa.gov
Address:  192.149.89.61

Most other sites will ping/telnet/ftp fine.

One other interesting data point is that a Sun running Solaris 2.3 on
the same network pings all these hosts just fine.

Any help here?  This is driving me nuts.  I've got a workaround (
telnet `host $1|cut -f3`) which works ok, but something is definitely
broken here and I want to know how to fix it.

Email or post.  I'll summarize if there's any interest.

Thanks in advance,
Tom (puzzled in Hampton Roads)
--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Wyvern Technologies, Inc | Hampton Roads' Premier Online Information System
(804) 622-4289           | (804) 627-1828, login guest to register

 
 
 

Broken Resolver?

Post by Jeff Ro » Mon, 22 Nov 1993 00:26:30




>Hi SVR4 Gurus,

>I have several machines running a variety of SVR4 OSs and I'm having a
>weird problem with the resolver.

>Our Intel based machines running vanilla SVR4.0 can resolve some
>Internet addresses, but not others.  For instance, our primary host
>cannot ping spacelink.msfc.nasa.gov.

>Here's what happens:

>$ ping spacelink.msfc.nasa.gov
>ping: unknown host spacelink.msfc.nasa.gov

>Same thing when I try to telnet.

>But here's what happens when I do a nslookup:
>Server:  ns.UU.NET
>Address:  137.39.1.3

>Non-authoritative answer:
>Name:    spacelink.msfc.nasa.gov
>Address:  192.149.89.61

>Most other sites will ping/telnet/ftp fine.

>One other interesting data point is that a Sun running Solaris 2.3 on
>the same network pings all these hosts just fine.

>Any help here?  This is driving me nuts.  I've got a workaround (
>telnet `host $1|cut -f3`) which works ok, but something is definitely
>broken here and I want to know how to fix it.

>Email or post.  I'll summarize if there's any interest.

>Thanks in advance,
>Tom (puzzled in Hampton Roads)

I got a simple answer for you, modify the file "/etc/netconfig" or use mine
which is following, this will allow programs such as telnet/ping/ftp etc
to use the nameserver.

                                Jeff

#
#       The Network Configuration File.
#
# Each entry is of the form:
#
# network_id semantics flags protofamily protoname device nametoaddr_libs
#
ticlts     tpi_clts       v     loopback        -       /dev/ticlts     /usr/lib/straddr.so
ticots     tpi_cots       v     loopback        -       /dev/ticots     /usr/lib/straddr.so
ticotsord  tpi_cots_ord   v     loopback        -       /dev/ticotsord  /usr/lib/straddr.so
tcp     tpi_cots_ord    v       inet    tcp     /dev/tcp        /usr/lib/tcpip.so,/usr/lib/resolv.so
udp     tpi_clts        v       inet    udp     /dev/udp        /usr/lib/tcpip.so,/usr/lib/resolv.so
rawip   tpi_raw         -       inet    -       /dev/rawip      /usr/lib/tcpip.so,/usr/lib/resolv.so
icmp    tpi_raw         -       inet    icmp    /dev/icmp       /usr/lib/tcpip.so,/usr/lib/resolv.so

>--

>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Wyvern Technologies, Inc | Hampton Roads' Premier Online Information System
>(804) 622-4289           | (804) 627-1828, login guest to register

--
.Sig??? you want a stinkin' .Sig???
Jeff Ross

 
 
 

Broken Resolver?

Post by Doug Lo » Wed, 24 Nov 1993 17:52:00




>Subject: Re: Broken Resolver?
>Keywords: svr4 internet resolver
>Date: 20 Nov 93 15:26:30 GMT


>>Hi SVR4 Gurus,

>>I have several machines running a variety of SVR4 OSs and I'm having a
>>weird problem with the resolver.

>>Our Intel based machines running vanilla SVR4.0 can resolve some
>>Internet addresses, but not others.  For instance, our primary host
>>cannot ping spacelink.msfc.nasa.gov.

[stuff deleted for brevity]

- Show quoted text -

>I got a simple answer for you, modify the file "/etc/netconfig" or use mine
>which is following, this will allow programs such as telnet/ping/ftp etc
>to use the nameserver.
>                                Jeff
>#
>#       The Network Configuration File.
>#
># Each entry is of the form:
>#
># network_id semantics flags protofamily protoname device nametoaddr_libs
>#
>ticlts     tpi_clts       v     loopback        -       /dev/ticlts
>/usr/lib/straddr.so
>ticots     tpi_cots       v     loopback        -       /dev/ticots
>/usr/lib/straddr.so
>ticotsord  tpi_cots_ord   v     loopback        -       /dev/ticotsord
>/usr/lib/straddr.so
>tcp     tpi_cots_ord    v       inet    tcp     /dev/tcp
>/usr/lib/tcpip.so,/usr/lib/resolv.so
>udp     tpi_clts        v       inet    udp     /dev/udp
>/usr/lib/tcpip.so,/usr/lib/resolv.so
>rawip   tpi_raw         -       inet    -       /dev/rawip
>/usr/lib/tcpip.so,/usr/lib/resolv.so
>icmp    tpi_raw         -       inet    icmp    /dev/icmp
>/usr/lib/tcpip.so,/usr/lib/resolv.so
>Jeff Ross


   I agree that this is necessary, Jeff, but it's not the complete answer to
the problem.  I've had the same situation here, and my netconfig file was set
up just as you advise from the start.

   As I see it, the problem is that the resolver code in SVR4+ is slightly
broken.  When you request a name to address translation, the SVR4+ resolver
converts it into a full domain validation test.  It's something like you
saying, "Here's a name--give me an address," but the resolver passing on the
request, "Here's a name--tell me everything there is to know about it."  If
any part of the request comes back in a form the SVR4+ resolver doesn't
expect, the entire request fails.  Here at Bloomsburg, we have PCs and Macs
that can resolve certain names just fine, but the resolver on the nameserver
itself (a SVR4 machine) can't resolve the same names.

   What to do about it?  Beats me.  USL wouldn't release their source code for
folks on the net to hack (unsurprising, and certainly within their rights).  
Maybe Novell will be a bit more forthcoming.  At any rate, until this code
gets fixed, we SVR4 users have to be very gracious in asking administrators at
sites we can't resolve to check their DNS files to see if there might be some
niggling little discrepancy from the RFC.  And we must always remember that
it's not an adversarial relationship--we're just trying to get _all_ DNS
systems singing from the same page of the songbook.

Doug Loss                        A crisis is when you can't say,
Data Network Coordinator         "Let's forget the whole thing."
Bloomsburg University

Voice (717) 389-4797

 
 
 

1. Kernel 1.1.60 breaks resolver

FYI to everyone who has applied the 1.1.60 patch that broke :-(

The file is linux/net/inet/af_inet.c.  Revert back to the .orig version
and recompile your kernel.  Everything will be fine then.

*=========*=================================================================*
| (*) (*) | \\\\   The preceding message has been brought to you by:   //// |

| <_____> | //// "We look for things...Things that make us go." -STNG  \\\\ |
*=========*=================================================================*

2. Setting 64k page size as default for _all_ applications...

3. Kernel 1.1.60 breaks resolver?

4. Unix Book

5. Resolver broken, libc5.0.9, Linux1.3.8, NetKitA.06, NetKitB.05?

6. Quake2 and Linux

7. no NFS in 2.2.12 - name resolver broken ?

8. network not reachable problem

9. DNS fails; resolver still broken in 2.x?

10. Make broken, top broken, flock errors, kernel modules broken

11. 2.5: ieee1394 still broken, vesafb still broken, ipv6 still broken

12. HELP! Linux broke WinNT and fdisk broke Linux!

13. PPPoE and IP MASQ: ftp is great, HTTP is broken, NNTP is broken