Fcc: +sent
Subject: Re: [leaf-user] Using HOSTS file
In-reply-to: Your message of "Thu, 06 Jun 2002 22:40:16 CDT."
<[EMAIL PROTECTED]>
--------
On Thu, 06 Jun 2002 22:40:16 CDT mds wrote:
> John Mullan wrote:
> >
> > 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?
[snip]
> 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
To clarify--and hopefully I'm not mis-speaking--this will tell
tinydns to tell dnscache that it is authoritative for the domain
"private.network". Seems like John probably wants
"mullan.dns2go.com" and "1.168.192.in-addr.arpa", possibly in
addition to "private.network".
> 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 . . .
The result should be that dnscache will forward requests for
DOMAINS to tinydns listening on /etc/tinydns-private/env/IP.
That's only half the battle; tinydns will also need to be
configured properly to reply for hosts in DOMAINS.
I agree that putting "dns2go.com" in DOMAINS would be a bad
idea because John would lose resolution for subdomain.dns2go.com
where subdomain!=mullan. Putting "mullan.dns2go.com" in there
to create a split horizon seems reasonable to me though; it
prevents having separate public and private names that refer to
the same resource.
> 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 . . .
Agreed you could use different names for all internal hosts, but
why? Having two names for the same resource can lead to a lot of
confusion, especially if you have hosts that move from the public
to the private network, e.g. roadwarrior notebooks.
Granted, tinydns can be tricky to setup and an incorrect config
can cause plenty of name resolution problems for internal hosts.
Once it is setup properly though, it should accomplish exactly
what John was trying to do--at least as I understand it.
--Brad
_______________________________________________________________
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
