Charles Steinkuehler wrote:
>
> > > 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).
root@bluetrout:/root
# ip addr
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope global lo
2: ipsec0: <NOARP,UP> mtu 16260 qdisc pfifo_fast qlen 10
link/ipip
inet 64.4.222.157 peer 64.4.222.158/32 scope global ipsec0
3: ipsec1: <NOARP> mtu 0 qdisc noop qlen 10
link/ipip
4: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10
link/ipip
5: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10
link/ipip
6: brg0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:fd:03:00:a2:75 brd ff:ff:ff:ff:ff:ff
7: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0
8: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:64:83 brd ff:ff:ff:ff:ff:ff
inet 64.4.197.65/26 brd 64.4.197.127 scope global eth1
11: wan1: <POINTOPOINT,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ppp
inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1
inet 64.4.197.99/32 scope global wan1
inet 64.4.197.100/32 scope global wan1
inet 64.4.197.101/32 scope global wan1
> 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.
<snip />
I'm beginning to believe that this maybe the problem. Remember, I
witness the queries in dnscache and witness the answers sent; but,
nothing gets back to dmz.
This is the real problem. If the query reaches dnscache, it processes
and answers it, why can't the answer get back to dmz?
root@bluetrout:/root
# ls -l /etc/dnscache/root/ip/
-rw-r--r-- 1 root root 0 Oct 9 19:10 127.0.0.1
-rw-r--r-- 1 root root 0 Oct 9 19:10 192.168.1
-rw-r--r-- 1 root root 0 Oct 9 19:10 64.4.197
-rw-r--r-- 1 root root 0 Oct 9 19:10 64.4.222.157
root@bluetrout:/root
# ls -l /etc/dnscache/root/servers/
-rw-r--r-- 1 root root 10 Sep 14 15:56
1.168.192.in-addr.arpa
-rw-r--r-- 1 root root 164 Oct 9 19:10 @
-rw-r--r-- 1 root root 10 Sep 14 15:56 private.network
root@bluetrout:/root
# cat /etc/tinydns-private/env/DOMAINS
private.network
1.168.192.in-addr.arpa
root@bluetrout:/root
# cat /etc/tinydns-private/env/IP
127.0.0.1
root@bluetrout:/root
# cat /etc/tinydns-public/env/IP
64.4.197.65
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
