From owner-freebsd-hackers Thu Oct 2 14:21:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24012 for hackers-outgoing; Thu, 2 Oct 1997 14:21:33 -0700 (PDT) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23995 for ; Thu, 2 Oct 1997 14:21:21 -0700 (PDT) Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.5/8.8.4) with ESMTP id RAA16152; Thu, 2 Oct 1997 17:21:00 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id RAA00258; Thu, 2 Oct 1997 17:24:50 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id RAA15045; Thu, 2 Oct 1997 17:16:12 -0400 (EDT) Date: Thu, 2 Oct 1997 17:16:12 -0400 (EDT) From: Thomas David Rivers Message-Id: <199710022116.RAA15045@lakes.dignus.com> To: freebsd-hackers@freefall.FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, rivers@dignus.com, tlambert@primenet.com Subject: Re: r-cmds and DNS and /etc/host.conf - *resolved* Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok - I just wrote and sent the following... without reading enough of the man page... but - the problem, for me at least, is resolved: See below... ] ] J"org wrote: ] > ] > David, why don't you simply start a caching-only nameserver, redirect ] > your resolv.conf(s) to it, and look at its debug output? This will ] > lead you *way quicker* to the solution about what names are being ] > looked up than any of our guesswork here in the mailinglist. ] > ] > A caching-only nameserver is a matter of one minute: ] > ] > cd /etc/namedb ] > sh make-localhost ] > named -d 2 -b /etc/namedb/named.boot ] > ] > FreeBSD ships with a reasonable default named.boot for a caching-only ] > server (which also has a bunch of comments for what to do to add a ] > secondary). ] ] Ok - ] ] Here's what I have in /etc/resolv.conf: ] ] domain vnet.net ] nameserver 127.0.0.1 ] ] And, to ensure things are consistent; I rebooted... ] ] Then, after the reboot, I did my rlogin - it worked ] immediately (notice; no nameserver is running on the machine ] where rlogind is running...) ] ] Then, I started named as suggested above; with the command: ] ] named -d 2 -b /etc/namedb/named.boot ] ] (I had already run the make-localhost script.) ] ] Now, my rlogins hang again... ] ] Unfortunately, named doesn't report *anything* at all.. Not ] a single byte... ] ] So, I added "options query-log" to the end of named-boot and ] redid all of this... ] ] named still doesn't report anything. ] ] ] Then, I added -q on the named command line (which shouldn't ] be needed, since options query-log is in named.boot). ] ] ] named still doesn't report anything. ] ] ] So, I changed the debug level from 2 to 10. ] ] ] named still doesn't report anything. ] ] ] As soon as I kill my local named; my rlogin succeeds... ] ] (This is the 2.2.1-RELEASE named; perhaps it's been compiled ] without the flags to report queries???) ] ] I also went through the entire exercise with "domain dignus.com" ] in /etc/resolv.conf - no change. ] ] Anyway - here's some of the text from /var/log/messages... it ] indicates that named was started (several times) and also that something ] is trying to go out the gateway interface to my ISP (which is down) via ] natd. My default route is to the external world... ] ] Oct 2 15:52:09 ponds named[497]: starting. named 4.9.4-P1 Tue Mar 25 12:43:20 ] GMT 1997 jkh@time.cdrom.com:/usr/obj/usr/src/usr.sbin/named ] Oct 2 15:52:09 ponds named[497]: Ready to answer queries. ] Oct 2 15:52:09 ponds natd: Failed to write packet back. (Network is down) ] Oct 2 15:52:17 ponds last message repeated 5 times ] Oct 2 15:52:18 ponds named[497]: dumping nameserver data ] Oct 2 15:52:18 ponds named[497]: finished dumping nameserver data ] Oct 2 15:52:19 ponds natd: Failed to write packet back. (Network is down) ] Oct 2 15:52:26 ponds last message repeated 6 times ] ] ] Any idea why my named isn't producing any debug info? ] ] - Dave Rivers - ] Well - reading the man page; I read to the bottom of the named man page to find /var/tmp/named.run. Here's what I see: datagram from [127.0.0.1].1066, fd 7, len 36; now Thu Oct 2 16:59:35 1997 named[349]: XX /127.0.0.1/puddles.dignus.com/A req: nlookup(puddles.dignus.com) id 17714 type=1 class=1 req: missed 'puddles.dignus.com' as '' (cname=0) forw: forw -> [198.41.0.11].53 ds=8 nsid=31064 id=17714 0ms retry 4sec resend(addr=1 n=0) -> [128.9.0.107].53 ds=8 nsid=31063 id=0 0ms resend(addr=1 n=0) -> [128.9.0.107].53 ds=8 nsid=31064 id=17714 0ms Followed by attempts to go higher toward the root to resolve this... So - the question is "what is puddles.dignus.com".... Here's the info: the rlogin machine: lakes.dignus.com 10.0.0.3 # ifconfig ed0 ed0: flags=8843 mtu 1500 inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:40:33:22:a2:6b the rlogind/gateway machine (where named is running): ponds.dignus.com 10.0.0.1 # ifconfig ed0 ed0: flags=8843 mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 66:66:77:00:0b:31 puddles.dignus.com does *not* appear in /etc/hosts on the gateway machine (which explains the search.) *But* - just where is "puddles.dignus.com" coming from? A quick grep in /etc on both of the machines indicates that puddles.dignus.com doesn't exist on "lakes.dignus.com" - but it is found in /etc/hosts.equiv on 'ponds.dignus.com'. Here's /etc/hosts.equiv on the gateway machine (ponds.dignus.com): #localhost #my_very_good_friend.domain localhost ponds ponds.dignus.com puddles puddles.dignus.com rivulet rivulet.dignus.com So - I think, somehow, /etc/hosts.equiv is being examined..., and since ponds.dignus.com isn't in /etc/hosts; the loolup for it is going to the resolver... Would someone care to explain why the hosts in /etc/hosts.equiv are being referenced for an rlogin? Now - fixing that particular problem lead me to another one (perhaps this is what's causing Terry's problem?) My .rhosts file contained many host names that weren't in my /etc/hosts; causing a "punt" to the nameserver. When I fixed up my .rhosts - *poof* - all of my problems disappeared. Thanks for the wonderful suggestion J"org! So, when unwanted resolver references (and timeouts) are occurring, here's my advice: 1) Use J"org's local cacheing nameserver trick to determine what hosts are trying to be looked up. 2) Look around for where that host might be referenced, some likely locations: /etc/hosts.equiv .rhosts .netrc - Dave Rivers -