Intranet Webserver/Application Servers and DNS

[DavidM]

My company does data processing for a number of clients that have private
network connections to our servers. We host many servers that our customers
use to perform various tasks using either Rich Client (desktop apps) or
browser-based applications, using Internet Explorer.

The way this had been setup before I arrived was that each client had a
hard-coded IP address to our servers.

This may not seem all too bad, since we're in a closed environment, but it
causes all kinds of issues when we're trying to upgrade/replace or down
server for maintenance. Each of our 50+ clients have hundreds of desktops
which may have hardcoded IP's into our shop.

Each of our customers have their own network and their own network support
folks for managing their own networks. Some of director Internet access and
others still use dialup.

What I would like to propose to my management is for us to host two DNS
servers... a primary and a secondary. I would like to create a local domain
called mycompany.intranet. I will then add host entries for each of our
production servers into this domain.

I do not want to use AD and I do not want our customers access my internal
DNS that our company uses. I would like a dedicated DNS server just for
customers to access our production serves.

Most of the services on my production servers are SQL Server related and
File Server related. The rest is web-based using IIS.

I'm not exactly sure what I should have the customers do. First thought is
this, from best approach to worse approach:

1) If they have a DNS server that they use locally or to access the
internet, then they should add a forward lookup to my domain.

2) If customers do not have any DNS or they use dialup Internet access, then
each of their clients should add a my primary/secondary DNS servers to their
TCP/IP settings. As they likely do not have any DNS entries anyway.

3) If client is unable to perform #1 or #2, the last option would be to
hardcode the TCP/IP address into their HOSTS file. By doing this, however,
it will defeat the purpose of using DNS... But at least, perhaps, the
majority of our clients will be using DNS.

Does this sound like logical way of doing it? Any foreseeable problems?
Most of my clients are XP/W2K/NT and a few 95/98/ME (Yuck!)

Finally, if I set up a primary/secondary DNS server, is it safe to assume
that if the primary server is down, paused, or the service is not running,
then the clients can still resolve to the secondary? If the secondary will
be down a great length of time, then I would then promote it from secondary
to primary?

To me this is the best logical way of supporting a server-centric
environment that I'm in. Most of the old timers think that they way we do
it today is perfectly acceptable. I, however, disagree and believe that we
should have the ability to control our own destiny without having our
customers dictate to us what we do. I.E., we can't swap servers to another
box and use a new IP because it is too much work for customers to change all
their clients...

 

[Andrew Hodgson]

My company does data processing for a number of clients that have private
network connections to our servers. We host many servers that our customers
use to perform various tasks using either Rich Client (desktop apps) or
browser-based applications, using Internet Explorer.

Can yo just itterate - are these public or private addresses? How do
the clients get to you if private addresses?

The way this had been setup before I arrived was that each client had a
hard-coded IP address to our servers.

This may not seem all too bad, since we're in a closed environment, but it
causes all kinds of issues when we're trying to upgrade/replace or down
server for maintenance. Each of our 50+ clients have hundreds of desktops
which may have hardcoded IP's into our shop.
Ok.

Each of our customers have their own network and their own network support
folks for managing their own networks. Some of director Internet access and
others still use dialup.

See above - how do the companies get to your servers - are these
public or private?

What I would like to propose to my management is for us to host two DNS
servers... a primary and a secondary. I would like to create a local domain
called mycompany.intranet. I will then add host entries for each of our
production servers into this domain.

Interesting because .intranet is not a valid public TLD could cause
problems - users may have to reconfigure their own DNS servers, or
even worse if they do not have any control of their DNS server (dialup
users?) they will have to use hosts files/hard coding again.

I do not want to use AD and I do not want our customers access my internal
DNS that our company uses. I would like a dedicated DNS server just for
customers to access our production serves.

No problem.

Most of the services on my production servers are SQL Server related and
File Server related. The rest is web-based using IIS.

I'm not exactly sure what I should have the customers do. First thought is
this, from best approach to worse approach:

1) If they have a DNS server that they use locally or to access the
internet, then they should add a forward lookup to my domain.

Best is to either create a TLD for this purpose with NS records
pointing to the servers hosting the Intranet DNS records, or create a
subdomain and delegate the NS records to your Intranet DNS servers.
This could work better if the Intranet servers are on private ips
because you can just create the subdomain and delegate it to a private
IP which only clients connecting through a VPN or whatever can access.

For example:

intranet.domain.com. in ns ns1.intranet.domain.com.
intranet.domain.com. in ns ns2.intranet.domain.com.
ns1.intranet.domain.com. in a private.ip.address.
ns2.intranet.domain.com. in a private.ip.address.

Then on your private servers:
acompanyserver.privatedomain.com. in a another.private.ip.address.

[...]

External clients wouldn't be able to resolve internal domains unless
they were connected to a VPN, and they wouldn't have to muck about
with nameserver configs their end either. Also, this can work with
public addresses, except for the fact that anyone could look up the
names of these servers.

[...]

Does this sound like logical way of doing it? Any foreseeable problems?
Most of my clients are XP/W2K/NT and a few 95/98/ME (Yuck!)

As I said we really need more details but I would certainly think
about looking at the above scenario.

Finally, if I set up a primary/secondary DNS server, is it safe to assume
that if the primary server is down, paused, or the service is not running,
then the clients can still resolve to the secondary? If the secondary will
be down a great length of time, then I would then promote it from secondary
to primary?

You don't need to promote DNS servers in this way - since they both
effectively return the same zone files, it will work fine.

To me this is the best logical way of supporting a server-centric
environment that I'm in. Most of the old timers think that they way we do
it today is perfectly acceptable. I, however, disagree and believe that we
should have the ability to control our own destiny without having our
customers dictate to us what we do. I.E., we can't swap servers to another
box and use a new IP because it is too much work for customers to change all
their clients...

This may still be an issue, you say the customers have code which
doesn't look up DNS, have you thought about how you would implement
this with the customers? You may be looking at a fairly large
project, but one which I feel would in the end be beneficial.

Hope this helps,
Andrew.

 

[Andrew Hodgson]

intranet.domain.com. in ns ns1.intranet.domain.com.
intranet.domain.com. in ns ns2.intranet.domain.com.
ns1.intranet.domain.com. in a private.ip.address.
ns2.intranet.domain.com. in a private.ip.address.

Then on your private servers:
acompanyserver.privatedomain.com. in a another.private.ip.address.

After a few pints I realised that should be:

companyserver.intranet.domain.com. in a another.private.ip.address

Sorry about that.
Andrew.

 

[DavidM]

Thanks for the reply, Andrew.

Let me clarify a couple things.

1) All our customers have a frame relay circuit into our data center. They
access all our servers via this frame relay using a 10.x.y.z address.

2) I have both a domain name registered called mydomain.com and
mydomain.net. The mydomain.com hosts are public web server that potential
customers can use to learn about our services and products. This points to
a public internet server. The mydomain.net domain is for internal use only.
I have our 10.x.y.z address registered on our internet DNS server.

Customers who access our private network and have internet access already,
don't have to do anything except type in mydomain.net in their browser and
DNS returns to them a 10.x.y.z address. It then will send them on their way
over our frame circuit instead of looking over the Internet.

3) I have set up a primary DNS server for our 10.x.y.z domain. A Secondary
has also been created.

4) Up until this point, the mydomain.net had only been used for our internal
intranet web server for our customers. Since we're deploying a few
web-based applications, we are going to have multiple dedicated internal web
servers. After some pondering, I decided that me having all our clients
continue to use the mydomain.net to get to our production servers is
probably a bad idea overall. Even though they may add a forward lookup to
my primary DNS (private network), their DNS will still look to TLD on the
internet to resolve the name. Even though it won't find a hit and then look
at the forward lookup on our server.

My thinking is that is I forget to re-register the mydomain.net and someone
else scarfs it up... then even though my internal network and servers are
fine... all my customers could all of a sudden when they type in their
browser http://mydomain.net may go to another website and never even hit my
server. If this were to happen, it could cause me more grief than its
worth.

Therefore, I just created a made-up domain suffix called mydomain.product
that I will use. This domain is not registered and since th suffix does not
end in .com, .net. .org, or anything... any TLD won't resolve and the users
DNS server should certainly do a forward lookup to my DNS. There is still a
slight possibly that ICANN could create a domain called "product" (for my
product name) but that would seem highly unlikely due to the unique name we
have.

Anyway - does this sound like a logical approach?

To recap:
1) Internet Public domain mydomain.com

2) Internal Public domain mydomain.net -- that is a registered name with DNS
pointing to a private 10net address for customers that already have internet
access. This kept me from having to install a DNS server inhouse. The
world cannot see this web server. Only our customers who have frame relay
circuits.

3) Create new private internal only domain called mydomain.product and host
on my internal DNS server.

4) Any of my customers that currently have Internet access can add a forward
lookup in their DNS to point to mydomain.product DNS server. Any other
customer that does not have any DNS or Internet access can simply add DNS
entries to their TCP/IP configuration.

My only other question with this approach is... is it necessary for me to
create my own TLD on my internal, private DNS? Currently, I simply
installed W2K DNS and created a new zone called mydomain.product and a
reverse lookup.

I realize there are still TLD defined and are really not necessary (I do not
believe.)

If I were to remove them and create my own TLD... how would I do this with
W2K DNS? Do I create a "." (period) TLD. Then create a subdomain called
"product", then create another subdomain called "mydomain"? Of course, I
would have all of this installed on the same DNS server.

I'm simply trying to get this working without a lot of maintenance and
headache. From best I can tell, it seems to work by leaving the TLD on my
private DNS???

BTW, the private DNS that I keep referring to only has host entries for the
production servers that our customers access. We have our own private DNS
server that is part of our AD W2K domain for internal use. Currently, we
have a forwrd lookup to our production server DNS so we can resolve using
domain name.

Sorry for the long-winded message.

Thanks for all your help!

My company does data processing for a number of clients that have private
network connections to our servers. We host many servers that our
customers
use to perform various tasks using either Rich Client (desktop apps) or
browser-based applications, using Internet Explorer.

Can yo just itterate - are these public or private addresses? How do
the clients get to you if private addresses?

The way this had been setup before I arrived was that each client had a
hard-coded IP address to our servers.

This may not seem all too bad, since we're in a closed environment, but it
causes all kinds of issues when we're trying to upgrade/replace or down
server for maintenance. Each of our 50+ clients have hundreds of desktops
which may have hardcoded IP's into our shop.
Ok.

Each of our customers have their own network and their own network support
folks for managing their own networks. Some of director Internet access
and
others still use dialup.

See above - how do the companies get to your servers - are these
public or private?

What I would like to propose to my management is for us to host two DNS
servers... a primary and a secondary. I would like to create a local
domain
called mycompany.intranet. I will then add host entries for each of our
production servers into this domain.

Interesting because .intranet is not a valid public TLD could cause
problems - users may have to reconfigure their own DNS servers, or
even worse if they do not have any control of their DNS server (dialup
users?) they will have to use hosts files/hard coding again.

I do not want to use AD and I do not want our customers access my internal
DNS that our company uses. I would like a dedicated DNS server just for
customers to access our production serves.

No problem.

Most of the services on my production servers are SQL Server related and
File Server related. The rest is web-based using IIS.

I'm not exactly sure what I should have the customers do. First thought
is
this, from best approach to worse approach:

1) If they have a DNS server that they use locally or to access the
internet, then they should add a forward lookup to my domain.

Best is to either create a TLD for this purpose with NS records
pointing to the servers hosting the Intranet DNS records, or create a
subdomain and delegate the NS records to your Intranet DNS servers.
This could work better if the Intranet servers are on private ips
because you can just create the subdomain and delegate it to a private
IP which only clients connecting through a VPN or whatever can access.

For example:

intranet.domain.com. in ns ns1.intranet.domain.com.
intranet.domain.com. in ns ns2.intranet.domain.com.
ns1.intranet.domain.com. in a private.ip.address.
ns2.intranet.domain.com. in a private.ip.address.

Then on your private servers:
acompanyserver.privatedomain.com. in a another.private.ip.address.

[...]

External clients wouldn't be able to resolve internal domains unless
they were connected to a VPN, and they wouldn't have to muck about
with nameserver configs their end either. Also, this can work with
public addresses, except for the fact that anyone could look up the
names of these servers.

[...]

Does this sound like logical way of doing it? Any foreseeable problems?
Most of my clients are XP/W2K/NT and a few 95/98/ME (Yuck!)

As I said we really need more details but I would certainly think
about looking at the above scenario.

Finally, if I set up a primary/secondary DNS server, is it safe to assume
that if the primary server is down, paused, or the service is not running,
then the clients can still resolve to the secondary? If the secondary
will
be down a great length of time, then I would then promote it from
secondary
to primary?

You don't need to promote DNS servers in this way - since they both
effectively return the same zone files, it will work fine.

To me this is the best logical way of supporting a server-centric
environment that I'm in. Most of the old timers think that they way we do
it today is perfectly acceptable. I, however, disagree and believe that
we
should have the ability to control our own destiny without having our
customers dictate to us what we do. I.E., we can't swap servers to
another
box and use a new IP because it is too much work for customers to change
all
their clients...

This may still be an issue, you say the customers have code which
doesn't look up DNS, have you thought about how you would implement
this with the customers? You may be looking at a fairly large
project, but one which I feel would in the end be beneficial.

Hope this helps,
Andrew.