> > I think Charles hit the nail on the head when he said: > > > > cs> You have to point the DMZ systems at the IP of dnscache, *NOT* tinydns, > > cs> as tinydns does not do recursive queries. I think that's the root of > > cs> your problem. Switch the IP in your non-working DMZ resolv.conf to the > > cs> IP used by hosts on your internal network, and the DMZ systems should be > > cs> able to resolve names. > > I agree with this; but, *HOW* can I point to that ip while on a > proxy-arp dmz? > > For that matter, what is that ip?
That IP is 0.0.0.0, which is *ANY* valid IP on your firewall. From a previous mail: > 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 Looks like you have tinydns listening on 64.4.197.65 (your WAN interface, IIRC), and 127.0.0.1 (loopback). These specific IP's will go to tinydns...queries to all other IP's will go to dnscache. I can't tell you exactly which IP's to use, since I haven't seen your full IP configuration data (at least I couldn't find it in a quick scan of previous messages in this thread). You should have at least two other IP's assigned on this system...the IP's assigned to the internal network NIC and the DMZ nic. You can use either one of these (or both) as the DNS server IP for your internal and DMZ systems. Note, however, that with both internal and DMZ systems pointed to the same dnscache process, you can't split off the internal (private.network) name-space. If you really need this feature, I think you'll need to run multiple dnscache instances, attached to seperate IP's, or take the leap to bind 9.x, which supports multiple views. NOTE: If you're running your proxy-arp DMZ with the DMZ interface assigned the same IP as your external interface, you may need to assign another unique IP to the firewall in order to have enough IP's to bind multiple instances of dnscache to. Alternatively, you could try adding another IP to the internal NIC, and bind an additional dnscache process to that (which has the benifit of not consuming another public IP)...IIRC, queries to IP's that are *NOT* on the DMZ network, but are local to the firewall will only traverse the input & output chains, not the forward chain, so you shouldn't have too much trouble tweaking firewall rules to get this to work. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ------------------------------------------------------- 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
