On Thu, 06 Jun 2002 23:01:43 EDT you wrote:
> Thanks for you help so far Brad......
Glad to help.
> I'm sure I'm missing something, but no luck. I had tried to set it up
> so that dnscache watches 192.168.1.254 and looks to tinydns. Not sure
> if that is what is supposed to happen or if I even got it that way in
> any of my attempted combinations.
That's the approach that I am using.
internal hosts -> dnscache -> tinydns for vmware.priv
-> tinydns for .70.168.192.in-addr.arpa
-> root DNS servers all other domains
I had it setup under LEAF, but currently I am only running that
configuration on my notebook. A masq'd set of vmware clients on
192.168.70.0/24 is my equivalent to your internal 192.168.1.0/24
net.
> If it helps, here are some configuration extracts, both what they are
> and what I have tried......
>
> DNSCACHE:
> LRP Internal 192.168.1.254 tried 127.0.0.1
192.168.1.254 is correct. That allows the internal clients to
reach dnscache.
> Query Hosts 192.168 tried 127.0.0.1
192.168 is correct, allowing hosts 192.168.*.* to access dnscache.
> FORWARDONLY NO tried YES
NO is probably what you want. YES would be used to forward all
of your requests to a single server, e.g. an upstream caching
name server.
> TINYDNS:
> Type PRIVATE kept PRIVATE
> Internal DNS 127.0.0.1 kept 127.0.0.1
Both correct.
> Data records....
> .1.168.192.in-addr.arpa::localhost
> +myrouter.private.network:192.168.1.254
> =mullan.dns2go.com:192.168.1.254
I think there are two problems here.
First:
=mullan.dns2go.com:192.168.1.254
^^^
should probably be
=mullan.dns2go.com:192.168.1.128
^^^
since you say mullan.dns2go.com is supposed to point to your web
server at 192.168.1.128.
Second:
According to http://cr.yp.to/djbdns/tinydns-data.html, you need
to add a line like ".mullan.dns2go.com:192.168.1.254" to create
a NS record that says 192.168.1.254 is the name server for
mullan.dns2go.com. Otherwise, tinydns will ignore queries for
mullan.dns2go.com.
After making these adjustments and running the tinydns-data
command[1], check to see if tinydns is working as expected.
Ideally, you'd run "dig @127.0.0.1 mullan.dns2go.com" or an
equivalent nslookup command.
Since you probably don't have dig available on the leaf box,
you can temporarily comment out all the nameserver lines in
/etc/resolv.conf execpt for the one with 127.0.0.1 and ping
mullan.dns2go.com. Ping should report the address for
mullan.dns2go.com as 192.168.1.128. If it doesn't something
is still wrong with the tinydns configuration.
Once tinydns is resolving mullan.dns2go.com and 192.168.1.128
properly, you'll need to make sure dnscache has files
/etc/dnscache/root/servers/mullan.dns2go.com
/etc/dnscache/root/servers/1.168.192.in-addr.arpa
with the text "127.0.0.1" in them to point dnscache to tinydns
to resolve those domains. Not sure about the leaf packages,
but there is a /etc/tinydns-private/env/DOMAINS file in the
version I am using that automatically creates them when from
/etc/init.d/tinydns when tinydns is started is restarted.
> Resolv.conf is......
> search nimc1.on.cogeco.ca tried 127.0.0.1 and
> private.network
> nameserver 127.0.0.1 no changes
> nameserver 216.221.81.53 no changes
> nameserver 24.226.1.47 no changes
> nameserver 24.226.1.90 no changes
You'll probably want the router to use dnscache to resolve names,
so the first nameserver line should use 192.168.1.254. tinydns
on 127.0.0.1 won't reply to queries for domains other than
mullan.dns2go.com and 1.168.192.in-addr.arpa so you don't want to
use it directly. You can keep the external nameserver lines if
you want to use your ISPs name servers when 192.168.1.254 doesn't
reply.
> Even when I did change resolv.conf it gets rewritten when I reboot.
Sounds like Dachstein. There are variables in /etc/network.conf
that control the "nameserver 127.0.0.1" line and whether or not
the other nameserver lines are added when the DHCP server hands
them out. I don't remember the variable names off-hand, but the
variable names and inline comments should make them obvious.
> To recap: The plan is to force internal network to resolve
> MULLAN.DNS2GO.COM to 192.168.1.128. External requests of course will
> already find their way to 192.168.1.128 via the INTERN_SERVERS in
> network.conf
>
> So any ideas?
Hope the comments above help. The first step is to get tinydns
working right, then move on to dnscache, and then the configuration
of the machines in your LAN (if they don't already use 192.168.1.254
for name service). If you can't get tinydns or dnscache working,
describe how they are failing and your configuration files and we
should be able to get it worked out.
--Brad
[1] I'm not using tinydns on leaf, but I think the tinydns-data
command is still present under leaf. It's used to "compile"
data into data.cdb and is probably run automatically from
/etc/init.d/tinydns.
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
------------------------------------------------------------------------
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
