hmmm...
we leave the nameserver blank when configuring to a dhcp client upstream,
although when using the @home network as the bandwidth provider we have had
greater compatability when we enter in the upstream providers's dns servers.
for example:
the default config with @home resolves www to the network root portal ,
without putting in the provider's nameserver this resolves correctly to the
e-smith default web page, if we add in the nameserver, then it resolves (
correctly from the customer perspective, but incorrectly technically) to
www.rdc1.mb.wave.home.com (for example) which is the "start portal" .
unless we configure the e-smith to be compatable to the upstream provider,
and in spite of whatever education we try to provide the user, at the first
perception of trouble the user in on the phone to the "free tech support"
who have the user start to reconfigure their clients ( you would think that
the 192.168.xxx.xxx address would be a tip to them :) but no) ...and before
the day is done the "free" tech support people are flaming the e-smith as
"incompatable" and alarming the customers who cannot begin to comprehend who
is wrong...
the real issue is the difference between the "server" and "service" but most
of the large isp's are committed to bundling many other "features" as part
of convergence, these "bundled" packages are much cheaper than "clean
bandwidth" so i have concluded that "when in Rome" :)
the original issue is exactly the opposite actually....
we have found that in static ip scenarios that we had to list at least one
upstream reliable dns server or the e-smith groaned....in this case the
wireless ISP provides static IP to user, the original dns servers upstream
were slow and thus an inital lag was barely detectable.... but... the
customer recieved a phone call from the ISP advising that the service would
be "faster" if they changed the upstream dns server ip....personally I have
to roll my eyes at this as they are already recieving an average 7-900K
downloads and their network was extremely snappy... but the customer
insisted that they had to put in this new info because they were assured
this would make their network...faster.
the point of my inital suggestion was to minimise my involvement, because if
upstream dns server config was in the admin, the user could add a secondary
dns server themselves, however with the config being in the console, we
usually have to make a visit.... ( i know we could do it remotely but any
boo-boo's and we still have to pack a lunch and go for a visit)
btw... as a aside on the same issue, a different provider reciently changed
their upstream dns servers and did not advise the users, all of the e-smiths
ground to a halt trying to resolve names to *send* mail only.... they could
browse and recieve mail.... but sending would timeout and bounce their
outbound mail. the e-smith dns servers seemed to work fine for browsing but
mail was bunk....If we left the dns blank in this case, would it work
better??
thanks
brent
----- Original Message -----
From: "Charlie Brady" <[EMAIL PROTECTED]>
> Brent, we are very seriously considering omiting the primary/secondary
> nameserver setup from the configuration. We are certainly recommending to
> some customers that they leave those settings blank, and you should
> consider doing the same.
>
> The name server in the e-smith server should be capable of resolving all
> names, but when configured in "forward only" mode as it is when a primary
> nameserver is configured leaves name resolution subject to 1) correct
> setting of the upstream ISP, and 2) competent configuration of the name
> server by the ISP.
>
> 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
>
