>>>>> "ED" == Edward Doolittle <[EMAIL PROTECTED]> writes:
ED> On 25 Feb 2000, Jake Colman wrote:
>> 1) Modify named.conf to contain the "query-source address" line.
>> Execute
>> 'ndc restart' and diald gets triggered. This only happens the first
>> time. Subsequent attempts at 'ndc restart' do NOT trigger diald.
>> Maybe somehow it 'knows' that its named.conf file was modified and it
>> does something different which causes diald to trigger?
ED> That's a little odd, but minor. You can investigate that later with
ED> tcpdump.
Well, this may be the final problem. A central part of fixing the "lost
packet" problem is to flush the named cache by doing a 'ndc restart' whenever
diald drops the link. When I try this, however, the 'restart' always
retriggers diald.
Here is the relevant part of the syslog:
Feb 27 11:31:25 firewall named[30222]: listening on [127.0.0.1].53 (lo)
Feb 27 11:31:25 firewall named[30222]: listening on [192.168.0.10].53 (eth0)
Feb 27 11:31:25 firewall named[30222]: listening on [175.41.1.2].53 (eth1)
Feb 27 11:31:25 firewall named[30222]: listening on [192.168.0.100].53 (sl0)
Feb 27 11:31:25 firewall named[30222]: Forwarding source address is [0.0.0.0].53
Feb 27 11:31:25 firewall named[30223]: Ready to answer queries.
Feb 27 11:31:25 firewall diald[19903]: Trigger: udp 207.198.222.7/53 1
92.168.0.100/1430
>> 3) I manually dropped the link with a 'kill -s SIGINT'. Once dropped,
>> I
>> cannot get diald to retrigger via a name resolution -- even if it's
>> not something already in its cache.
ED> Check your /etc/resolv.conf file. It should look something like
ED> search
ED> jnchome.com
ED> 127.0.0.1
ED> 207.198.253.36
ED> 207.198.222.7
My resolve.conf was almost like this. Instead of the localhost address, I
used the actual address (192.168.0.10). I fixed it as you suggested and now
the link comes up correctly to resolve addresses for 'ping', etc.
>> 4) I tried an nslookup of something not in the cache and I got the
>> following:
>>
>> *** firewall.jnchome.com can't find www.apple.com: Non-existent
>> host/domain
ED> You've found the Achilles Heel of this workaround. nslookup won't
ED> bring up the link if you point it to your local server. Use a server
ED> option in .nslookuprc to point it elsewhere with a server directive
ED> and it will correctly bring up the link to resolve all names except
ED> those in your local net. It's really a bit of a quirk in nslookup,
ED> to only try one server.
I don't quite understand this. The 'server' option should be specified to
point nslookup to one of my ISP's name servers? It will first check my local
cache and, if not found, query my ISP?
>> It seems like named is refusing to contact anyone after I made the
>> change for "query-source address".
ED> No, the link just isn't coming up on named to named requests. The
ED> trick now is to get it to come up on other app to named requests.
ED> That depends on setting /etc/resolv.conf correctly.
I guess that substituting 127.0.0.1 for 192.168.0.10 as my first nameserver
solved that problem. The only problem left, as stated above, is that 'ndc
restart' is forcing up the link.
Thanks again for all your help thus far!
...Jake
--
Jake Colman
Principia Partners LLC Phone: (201) 946-0300
Harborside Financial Center Fax: (201) 946-0320
902 Plaza II Beeper: (800) 928-4640
Jersey City, NJ 07311 E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]
web: http://www.ppllc.com
microsoft: "where do you want to go today?"
linux: "where do you want to go tomorrow?"
BSD: "are you guys coming, or what?"
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
