Charles Steinkuehler wrote: > > > > >does anybody have a proxy-arp dmz and also running tinydns & > dnscache? > > > > > > > >thought that I'd resolved this sometime ago; but, tonight, for life > of > > > >me, I cannot get dmz hosts to resolve addresses for remote internet > > > >sites solely via tinydns-public and dnscache ;< tinydns tries to > > > >resolve the name and gives up, without so much as asking dnscache. > as a > > > >test, I do same query from the internal network and dnscache > answers > > > >immediately. > > > > > > > >actually, if I add other remote dns servers to /etc/resolv.conf on > dmz > > > >hosts, then it works. > > > > > > > >oddly enough, netware servers on the dmz do not exhibit this > problem . . > > > > > > You may want to give us information about your resolv.conf file on > the > > > failing DMZ machine, then try to debug with nslookup or the more > recent > > > bind tools (dig, hosts...). > > > > This does *not* work: > > > > nameserver 64.4.197.65 > > search PlatinumAire.net > > > > This does work: > > > > nameserver 64.4.197.65 > > nameserver 207.7.4.66 > > nameserver 207.7.4.67 > > nameserver 207.112.196.69 > > nameserver 206.54.244.3 > > nameserver 206.54.244.2 > > search PlatinumAire.net > > > > Remember, 64.4.197.65 resolves the tinydns-public domain > > (PlatinumAire.net) properly; but, will not goto dnscache to resolve > > remote domains . . . > > You have to point the DMZ systems at the IP of dnscache, *NOT* tinydns, > as tinydns does not do recursive queries. I think that's the root of > your problem. Switch the IP in your non-working DMZ resolv.conf to the > IP used by hosts on your internal network, and the DMZ systems should be > able to resolve names. > > NOTE: You also need to tell dnscache it's OK to answer queries from the > DMZ address space, if you haven't already.
Charles, yes, I understand what you're saying. However, all of these are running on the dcd: dnscache, tinydns-private, tinydns-public. We are using the stock jnilo package. Unfortunately, I suspect that the modifications to djbdns that were made to accommodate leaf routers may preclude dnscache responding to the dmz. Look here: root@bluetrout:/root # netstat -anp | grep dns (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 28373/dnscache udp 0 0 0.0.0.0:53 0.0.0.0:* 28373/dnscache udp 0 0 64.4.197.65:53 0.0.0.0:* 28326/tinydns udp 0 0 127.0.0.1:53 0.0.0.0:* 28324/tinydns Yes, I've set it up to listen to addresses from the dmz. What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
