Date: Thu, 2 Oct 1997 17:16:12 -0400 (EDT) From: Thomas David Rivers <rivers@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* Message-ID: <199710022116.RAA15045@lakes.dignus.com>
next in thread | raw e-mail | index | archive | help
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710022116.RAA15045>