Charles Steinkuehler wrote: <snip />
> So...it looks like either dnscache is mis-configured (bad send-from IP), > or more likely, that your masquerade rule connecting the internal > network with the DMZ is mangling (masquerading) the return traffic. Why am I thinking about correcting the error and dnscache will server both networks? > I'd suggest configuring dnscache to listen on the 64.4.197.65 IP for > your DMZ hosts. You can setup a second dnscache to listen on > 192.168.1.254 for your internal network. The two tinydns instances can > be run on loopback interfaces (there's more than just 127.0.0.1 > available, remember...in fact, there's a whole class A) or additional > private IP's from your internal network (ie 192.168.1.253) as desired. Yes, I see the logic; but, what is wrong -- or, worse, impossible -- with my desire to correct the underlying problem and dnscache will serve both networks? Since dnscache cannot be poisoned, and the answers it gathers are authoritative, and we can restrict the source of questions to which it responds, why do we need more than one (1) to serve these two (2) networks? Isn't this really a routing and ipchains problem? Is there a solution in that context? 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
