On Fri, 11 Oct 2002 00:03:11 EST mds wrote:
> Brad Fritz wrote:
>
> Actually, what I want is:
>
> [a] one (1) authoritative tinydns for my.public.domain
> (PlatinumAire.net);
> [b] one (1) authoritative tinydns for my.private.domain
> (private.network); and
> [c] one (1) dnscache to handle all recursive queries for *both* of these
> domains.
>
> Is that clear?
Yes, although I can't think of a (non-convoluted) way to
accomplish it with djbdns, unless you relax the requirement
for a single dnscache.
> It sounds alot like what you have . . .
The setup I use is one (1) authoritative tinydns for both
my.public.domain *and* my.private.domain with one (1) dnscache
to handle all recursive queries for both. It works for me
since I don't have hosts in my.private.domain that I am worried
about exposing to the DMZ. More precisely, I don't have *any*
my.private.domain hosts defined.
> > Although the wildcard bind on dnscache (0.0.0.0:53) confuses me.
> > Please correct my diagram if I was off in la-la land when I drew
> > it.
> >
> > 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 b
>e
> > 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?
Your netstat output shows dnscache on 0.0.0.0:53. I believe
more typical setups would use 192.168.1.254:53. My installs
do, anyhow. (/etc/dnscache/env/IP contains "192.168.1.254".)
Your dmz host would use
nameserver 192.168.1.254
in /etc/resolv.conf . With shorewall, I would add
ACCEPT dmz fw udp domain
ACCEPT dmz fw tcp domain
rules to allow this traffic. I don't recall the DCD equivalent
offhand. The fact that the dmz is proxy-arp rather than NATed
shouldn't have any impact on the solution. The important part
is that there is a route between the dmz and the dnscache address.
> > I have two working proxy-arp setups where proxy-arped DMZ hosts
> > query dnscache on a Bering box. Via appropriate
> > /etc/dnscache/root/servers entries, dnscache queries
> > tinydns-private on 127.0.0.1:53 for domains I have selected. Eg:
> >
> > # cat /etc/dnscache/root/servers/host.mydomain
> > 127.0.0.1
>
> Do you run two (2) instances of dnscache? One for internal, private
> network and another for dmz?
No. My needs don't dictate isolation of the DMZ and LAN
authoritative name servers, so I can get by with a single
shared tinydns instance. Since I only have one (1) tinydns
running, I only need one (1) dnscache instance to sit in
front of it and resolve queries that my tinydns instance
isn't authoritative for.
> # 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
>
> # cat /etc/dnscache/root/servers/private.network
> 127.0.0.1
Looks like the default setup. No problems there.
> > so that a query from the DMZ for host.mydomain is routed
> > like so:
> > dmz host --> dnscache on Bering --> tinydns-private on Bering
> > (if not already cached)
I should have added:
and a query from the LAN for host.mydomain is routed:
lan host --> dnscache on Bering --> tinydns-private on Bering
(if not already cached)
to be complete.
> I do not understand how jnilo's instructions get you to this design:
>
> <http://leaf.sourceforge.net/devel/jnilo/dnscache3.html>
Those instructions didn't. The most relevant passage is
http://leaf.sourceforge.net/devel/jnilo/tinydns3.html#AEN173
in Jacques' tinydns docs which describes how to set
/etc/tinydns-private/env/DOMAINS which the startup scripts use
to populate /etc/dnscache/root/servers/ .
> _Why_ would anything on the dmz want anything in tinydns-private?
In the example I presented, "host.mydomain" is for a Domino
server in the DMZ. The name "host.mydomain" is only used
internally (on the LAN and in the DMZ) and doesn't need to be
public knowledge...not to mention a third, not always
cooperative, party is involved in changes to the (externally
hosted) public authoritative name servers. The solution I
used was the path of least resistance.
> _Why_ would anything on the dmz want anything in tinydns-private? By
> definition, the dmz cannot know anything about the internal, private
> network?
In my case that wasn't a requirement. "host.mydomain" refers to
a host in the DMZ, not the LAN. tinydns-private is misnamed in my
configuration.
> At anyrate, _how_ do you point the dmz at dnscache? What is the address
> you use in /etc/resolv.conf? _How_ have you configured your
> dnscache/tinydns'es?
Sorry about the fake public addresses and domains. I would
prefer not to post that information without my customer's
consent.
# cat /etc/dnscache/env/IP
192.168.1.254
# cat /etc/dnscache/env/IPQUERY
192.168
12.34.56
# cat /etc/tinydns-private/env/DNSTYPE
PRIVATE
# cat /etc/tinydns-private/env/IP
127.0.0.1
# cat /etc/tinydns-private/env/DOMAINS
1.168.192.in-addr.arpa
private.network
host.mydomain
I don't use tinydns-public since my customers' public
authoritative DNS servers are hosted on better connected
networks.
> My problem is that I can see the dmz queries processed and returned by
> dnscache; but, they do *not* make it back to the dmz. I've been trying
> to say this for two (2) days; but, nobody picks up on this. I watch
> this:
>
> tail -f /var/log/dnscache/* | tai64nlocal
>
> I see the query come in and process and go back out; but, the dmz host
> does *not* receive any answer and eventually times out.
Can you post a sample dnscache log entry for us? I *think*
dnscache is replying because it's bound to 0.0.0.0:53 which
includes "64.4.222.157:53". Coupled with the "sleight-of-hand"
you described leads to the very confusing:
(Abbreviated and reformatted to be easier on the eyes.)
[a] 59:46 input - eth1 PROTO=17 64.4.197.69:32779 64.4.197.65:53
[b] 59:51 input - eth1 PROTO=17 64.4.197.69:32780 64.4.222.157:53
[c] 59:52 output - eth1 PROTO=17 64.4.197.65:53 64.4.197.69:32780
[d] 59:52 input - eth1 PROTO=1 64.4.197.69:3 64.4.197.65:3
[e] 59:56 input - eth1 PROTO=17 64.4.197.69:32779 64.4.197.65:53
[f] 00:01 input - eth1 PROTO=17 64.4.197.69:32780 64.4.222.157:53
[g] 00:01 output - eth1 PROTO=17 64.4.197.65:53 64.4.197.69:32780
[h] 00:01 input - eth1 PROTO=1 64.4.197.69:3 64.4.197.65:3
[i] 00:07 input - eth1 PROTO=17 64.4.197.69:32780 64.4.197.65:53
[j] 00:07 output - eth1 PROTO=17 64.4.197.65:53 64.4.197.69:32780
My best guess at what's going on is:
1. Ping on dmz host (.69) attempts to resolve cdw.com using
64.4.222.157 [b].
2. Either tinydns or dnscache replies from address 64.4.197.65,
*not* 64.4.222.157 [c]. (What is the value of
/etc/dnscache/env/IPSEND ?)
3. The dmz shuns the request with an icmp port unreachable
message [d] because it isn't expecting a UDP response
packet from 197.65. (It sent to 222.157, after all.)
Overall the whole setup after the "sleight-of-hand" you described
has me fairly confused, so I may easily be misinterpreting
something.
I can't tell you how to make your current setup work. No offense
intended, but it sure feels like fitting a square peg in a round
hole to me.
Jacques' documentation and default configuration isn't really
intended (AFAICT) to do what you are trying to accomplish. If
you want to use djbdns tools and have separate DMZ and LAN
tinydns instances, you will also need to add a second instance
of dnscache to act as a "front-end" to the tinydns-public
(which would be more appropriately called "tinydns-dmz" in your
case).
Hope the above information has been helpful. Let me know if I
should clarify anything or can provide more information about my
setup to help out.
--Brad
-------------------------------------------------------
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
