Yes I think the host configuration screen is a great addition. I'm not
Linux literate enough to completely follow or implement your technical
suggestions outlined. I just found the previous use of DNS entries in the
console, if not technically correct, at least appeared to work just fine.
> -----Original Message-----
> From: Charlie Brady [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 02, 2001 9:32 PM
> To: Darrell May
> Cc: [EMAIL PROTECTED]
> Subject: RE: [e-smith-devinfo] Revised console in e-smith-base-4.1.2-5
>
>
>
> On Tue, 2 Jan 2001, Darrell May wrote:
>
> > Maybe I misunderstand but I thought the last DNS reply (shown below)
> > acknowledged that this needed to be revisited.
>
> > -----Original Message-----
> > From: Gordon Rowell [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 01, 2001 12:27 PM
> > To: Owen n Fleur Chambers +Patrick
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [e-smith-devinfo] Re: DNS Primary/Secondary (was Re:
> > [e-smith-devinfo] 4.1 b2)
> >
> > On Tue, Jan 02, 2001 at 07:03:22AM +1100, Owen n Fleur
> Chambers +Patrick
> > <[EMAIL PROTECTED]> wrote:
> > > that's about the strength of it, I need to be able to
> point e-smith to my
> > > works primary Dns server and possibly to my other e-smith server
> >
> > OK - we need to revisit the delegated DNS settings.
>
> I took Gordon's answer to mean that the delegation of a zone or of all
> name resolution to another local server will need to be considered for
> some circumstances, not ncessarily that the console should
> support setting
> of DNS forwarders.
>
> > The case given identified where you need to include DNS entries for
> > support of an internal DNS server on your LAN.
>
> In that case I would recommend that particular zones should
> be delegated
> to the internal DNS server, or in some circumstances, all
> name resolution
> should be delegated to another server. For instance, in the case of a
> second e-smith server, we should consider running no caching
> name server
> on the "secondary" server, and just setting the IP of the "primary"
> e-smith server in /etc/resolv.conf on the "secondary" server,
> and if the
> DHCP server is enabled on the "secondary" server, refer the
> DHCP clients
> to use the DNS server of the "primary" server.
>
> > In this case you would want DNS1 to be your internal DNS server
> > and DNS2 to be your gateway DNS. I have a client with this set-up.
>
> This is not guaranteed to work. Your server may query DNS2 regarding a
> internal name, and it would get a "no such domain" reply.
>
> > They use an internal DNS server, which does not publish
> publicly, for
> > pointing via hostname to all their internal servers which use of
> > course internal ip addresses. This saves having host table
> entries on
> > all the workstations.
>
> Quite logical. However for this to work reliably, all queries
> for those
> domains must be directed to the internal DNS server, and
> delegation is the
> correct way to do that, not setup of "forwarders".
>
> > The other reason you may wish to use other then your
> gateway DNS entries is
> > that if you use an external DNS service for your domain
> registration and
> > name hosting. In this case you may wish to point your DNS1
> to your external
> > DNS service so that changes made to your domain name are effective
> > immediately on your LAN. If you only have your gateway DNS
> you would have
> > to wait until your gateway DNS server performs it's
> updates. Sometimes a
> > full day or more wait.
>
> Since the e-smith server hosts a caching name server, it will cache
> replies from the external DNS server for as long as the TTL value
> indicates. Setting the external DNS server as a forwarder does not
> guarantee rapid propogation. Reducing the TTL values in the
> records for
> the zone prior to making changes is the way to get changes propagated
> quickly.
>
> In any case, another new change may either help or hinder access to
> externally hosted sites related to your domain name. Consider the no
> unusual case of an e-smith server handling mail for
> domain.com, where the
> web site www.domain.com is hosted externally. Since e-smith 4.0 was
> released, this case was handled by the LAN machines being named
> *.e-smith.domain.com, with the server itself known by various names,
> including www.e-smith.domain.com.
>
> As you are no doubt aware, the "e-smith" interpolated into the LAN
> machine's names has been a source of confusion and irritation for many
> people. As a result, the interpolated "e-smith" is now optional. As a
> result of this change, however, the externally hosted
www.domain.com would
become invisible to the machines on the LAN - www.domain.com would now
resolve to the e-smith server's internal interface address, e.g.
192.168.1.1.
Our solution to this dilemma is to offer a host configuration screen which
allows each name in the *.domain.com domain to be assigned to any IP
address on your LAN, or to an external IP address. By default, "www",
"proxy", "mail" and "e-smith-manager" are set to the LAN IP address of the
server. In the example that you have given, "www" can be set to the IP
address of the external web host. "www.domain.com" will then resolve to
the externally hosted web site without reference to the external DNS.
The host configuration screen can also be used to assign other names to
machines on your LAN; this feature will be used, for instance, to assign
names for network printers. The hosts screen also allows MAC addresses to
be assigned to IP addresses and names - this information is used to prime
the DHCP configuration, so that, e.g, printers, other servers, etc, can be
assigned fixed IPs and descriptive names via DHCP.
I hope that you will find that this system will satisfy all your naming
needs.
Regards
Charlie Brady [EMAIL PROTECTED]
http://www.e-smith.org (development) http://www.e-smith.com (corporate)
Phone: +1 (613) 368 4376 or 564 8000 Fax: +1 (613) 564 7739
e-smith, inc. 1500-150 Metcalfe St, Ottawa, ON K2P 1P1 Canada
