Best-practices for moving from a private (.local) to a public domain(.com)

I have an AD domain (Windows 2000 DC) that is private, e.g. named
'DOMAIN.local'.
We have recently purchased a.com domain name and are running web and
email servers for this domain inside of the .local network.
I have dns records pointing to our external IP, and a cisco firewall
that routes the packets to and from the proper internal servers. We
also use the web and database functionality internally, so these
servers are dual-homed.

I think that I would like for some, or all, of these hosts to exist in
the .com domain, even just so that mail headers and such show the
proper domain name, and not 'svr-mail.domain.local'.

What experiences have you had maintaining an internal business network
that also has internet-facing servers? Are there any resources that
address this specifically?

I have questions like:
- Should I change the name of the internal domain, in order for
internet-facing hosts to have the proper domain name? Is this even
necessary? Is this what is typically done?
- Do I need a second domain?
- What separation should there be between internal and external
resources, if those resources are sometimes shared?
- If I have a server that lives in the public facing domain, how do I
allow clients from the internal domain to access it's services in an
AD-integrated fashion? (i.e. trust)

I am really looking for documents or books that deal with this
subject, or any tips that the group may have.

Thank you very much for your help, in advance.
Robert Waters

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

even if both internal and external domain have the same name, you should
do split dns.

By "changing" the domain name, that's mean renaming the domain. And it's
always a pain. Not the procedure by itself, but everything around that
get broken

I shared my experience of domain rename of my blog:
http://lordoftheping.blogspot.com/20...name-done.html
http://lordoftheping.blogspot.com/20...wsus-down.html

I would better keep separate domain, and maybe create a local zone with
the public name. So www.mydomain.com would resolve to the local
webserver and not the public one.

I would not dualhome servers, especially on the internet side. Did you
try to implement nat on your firewall or thought about reverse proxy ?


Cordialement,
Mathieu CHATEAU
french blog: http://www.lotp.fr
english blog: http://lordoftheping.blogspot.com


robert.waters a écrit :
> I have an AD domain (Windows 2000 DC) that is private, e.g. named
> 'DOMAIN.local'.
> We have recently purchased a.com domain name and are running web and
> email servers for this domain inside of the .local network.
> I have dns records pointing to our external IP, and a cisco firewall
> that routes the packets to and from the proper internal servers. We
> also use the web and database functionality internally, so these
> servers are dual-homed.
>
> I think that I would like for some, or all, of these hosts to exist in
> the .com domain, even just so that mail headers and such show the
> proper domain name, and not 'svr-mail.domain.local'.
>
> What experiences have you had maintaining an internal business network
> that also has internet-facing servers? Are there any resources that
> address this specifically?
>
> I have questions like:
> - Should I change the name of the internal domain, in order for
> internet-facing hosts to have the proper domain name? Is this even
> necessary? Is this what is typically done?
> - Do I need a second domain?
> - What separation should there be between internal and external
> resources, if those resources are sometimes shared?
> - If I have a server that lives in the public facing domain, how do I
> allow clients from the internal domain to access it's services in an
> AD-integrated fashion? (i.e. trust)
>
> I am really looking for documents or books that deal with this
> subject, or any tips that the group may have.
>
> Thank you very much for your help, in advance.
> Robert Waters
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjebR4ACgkQR16rF5v5prCXegCfdOwzn5GToL pQsRCAWs+zl9AU
uT0An2qmNLfEXvvIyptPVVbrBRmbrlQD
=4T9C
-----END PGP SIGNATURE-----

"robert.waters" <(E-Mail Removed)> wrote in message
news:3cfe268b-f3ce-4a10-91ce-(E-Mail Removed)...
> I have questions like:
> - Should I change the name of the internal domain, in order for
> internet-facing hosts to have the proper domain name?

No. It is unrelated, they have nothing in common beyond both being spelled
"d-o-m-a-i-n".

> Is this even necessary?

No. It is unrelated, they have nothing in common beyond both being spelled
"d-o-m-a-i-n".

Is this what is typically done?

No. It is not.

> - Do I need a second domain?

No.

> - What separation should there be between internal and external
> resources, if those resources are sometimes shared?

There is no separation because there is no relationship,....so there is
nothing to "separate".

> - If I have a server that lives in the public facing domain, how do I
> allow clients from the internal domain to access it's services in an
> AD-integrated fashion? (i.e. trust)


"lives in the public facing domain,"?. Well, servers don't live in domains
they live on a networks, so what network does it actually live in? Domains
are not networks,...networks are not domains.

You're making way more of it than there actually is. It is simple as this:

Create a New "non-AD" Zone on your AD/DNS Server. Add whatever Records are
required. If the target machine is already a Domain Member on the LAN then
use a CNAME entry in the new Zone that points to the correct "A" Record in
the AD Zone,...if the machine exists outside the network and outside of AD
then use an "A" Record instead of a CNAME.

The Public resolves your Public Names via the ISP's DNS (not your DNS).
The LAN Users resolve your Public Names via your AD/DNS (not the ISP's DNS)
Hence the term "Split-DNS".
Therefore your users may resolve the same Name to an Internal IP# or any IP#
you specify,...while at the same time the Public users always resolve to a
Public IP#.

Make sure internal LAN Machine resolve to the correct LAN IP# (not a Public
IP).
Do *not* try to make "U-Turns" with the Firewall.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------