John Mullan wrote:
>
> Thanks for you help so far Brad......
>
> 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.
>
> 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
> Query Hosts 192.168 tried 127.0.0.1
> FORWARDONLY NO tried YES
>
> TINYDNS:
> Type PRIVATE kept PRIVATE
> Internal DNS 127.0.0.1 kept 127.0.0.1
> Data records....
> .1.168.192.in-addr.arpa::localhost
> +myrouter.private.network:192.168.1.254
> =mullan.dns2go.com:192.168.1.254
>
> 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
>
> Even when I did change resolv.conf it gets rewritten when I reboot.
>
> 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?
Actually, this is the way dns _should_ work -- you do *NOT* own the
domain dns2go.com, so dnscache will always look to the internet
nameservers for that domain. The real problem is that, even though your
dns queries _are_ being directed toward your external ip, *NO* port
forwarding is allowed from internal to external and back to internal ;>
Now, if you really want to do what you say and if you do *NOT* care
about resolving anything else in the domain dns2go.com, you can try
adding this:
private.network
to this:
/etc/tinydns-private/env/DOMAINS
and then:
svi tinydns restart
svi dnscache restart
I cannot guarantee the results; but, it seems likely that you will be
telling dnscache that, indeed, you do have bailiwick for the domain
dns2go.com -- instead of that domain's rightful nameservers -- and you
maybe able to fool some of the people some of the time . . .
I do _NOT_ recommend this approach, since I cannot know whether or not
this tomfoolery will lead to other, less impressive results. Instead, I
recommend that you tell your internal boxen to look for whatever
192.168.1.128's legitimate .private.network name really is . . .
hth
--
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 . . .
_______________________________________________________________
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
