Internal Subdomain Externally Routable (Is this a problem?)

Perhaps I should also mention that the internal domain is an AD domain, where I intend to house all my users and resources.  If it is a subdomain of the external domain, should I create domain controllers for both "jcghome.com" and one for a child domain of "int.jcghome.com"?  Or is simply having one AD server hosting "int.jcghome.com" as root OK?

Your domain won't be accessible from the internet.

If you open port 80 on your firewall and point it to web server (www.jcghome.com) that will be the only thing that is accessible from the internet.

I strongly suggest putting the web server in a DMZ, most routers/firewalls nowadays allow for this very easily.

Thanks aindelicato, for your reply!  This is the second time I asked the question to a panel of experts, with a similar & obvious response... so I'm thinking it was a dumb question.  I suppose if it simply resolves to my external IP address, there's nothing "public" about it if kept safe behind the firewall (using TMG 2010).  

Maybe I have a misunderstanding of the configuration.  What prompted my question was this from http://technet.microsoft.com/en-us/library/cc755946(v=ws.10)  :



My internal domain, int.jcghome.com, would technically not be unique since my provider allows wildcard domain lookups... and even though I'm sure name resolution would never be an issue, I'm hoping to not change any of this for a long time and want to implement what's "right" and as cleanly as possible.

For my servers in the DMZ, would they also belong to int.jcghome.com in AD, or would they be belong to jcghome.com in AD?

Also, if I am way off and spouting nonsense, don't be afraid to say so.  Until recently I never really put much thought into my domain setup.

That's how I've been running things for the last 12 years... but not because of any concious design.  Rather, it was me sitting in a dorm room figuring out this new "Active Directory" thing from Microsoft, and I ended up with an internal domain that I've never changed since.  During that same time, I have changed my external domain many times.  I do like having them detached from each other for that reason...

But this time around, I'd like to "design" it correctly, and I guess I have a mental block when thinking of separate domains as the correct design when that's what I accidentally did as a kid.

I considered "making up" my own TLD for my internal domain, but internet people vehemently oppose that because of possibility of ICANN reserving it down the road.  And then there's me, who has used "jcg.com" internally for 12 years (which is obviously registered to somebody else)... without any issues at all.

I'm starting to agree that for my situation, the better solution might be what you suggested, footech.  Separate external vs. internal domains... if for no other reason than it decouples them.  I could also eliminate whatever minor risk of duplicating names by registering my internal one as well if I really wanted.

Stuff to think about, thanks for your replies!

I wouldn't say that using .com for an internal TLD is not recommended (neither does the Technet page).  Just that when you do, you should make sure that domain name is unique.  When using something like .local as the internal TLD, there is no risk of that (unless you create it yourself), because .local is not resolveable on the internet.

If you decide to go the subdomain route, even though you may have the "jcghome.com" domain registered, you don't have to set up a DC for it.  Your internal, AD domain could be "int.jcghome.com".  You don't have to have any machines, whether in the DMZ or wherever that are part of an actual AD domain called "jcghome.com".  Even though you may have a webserver that is reachable via "www.jcghome.com", that machine could be part of the "int.jcghome.com" domain (or any other), and have a host name of "spanky" (and so the FQDN would be "spanky.int.jcghome.com") or whatever else you want to call it.

It is not ideal to have the wildcard be able to resolve, but it's pretty much the same scenario as what you've used for years, "jcg.com", which you don't own and haven't had a problem with.  Just because the FQDN isn't unique between across all domains (internal and external) doesn't guarantee that you will have a problem.  Just that it can make troubleshooting a problem more difficult.

This hits it pretty much right on the head, thanks.  I looked at my TZO control panel online, and I can indeed disable wildcards, and add my own A records.  So everything you guys offered up has been a big help.  I learn much better being able to discuss my ordeal with people vs. scanning search results and forums where everybody thinks their opinion is irrefutable.

My only remaining curiosity is for friends who VPN into my network, or authenticate to it for any other reason.  If my internal domain is entirely different, say "spanky.net" and my external domain is "jcghome.com", I'm wondering if they will be confused when I tell them to enter spanky.net\username for authentication to vpn.jcghome.com.  I suppose those same types of things would exist even with the subdomain approach.  For example, they'd have to use int.jcghome.com\username for authentication to vpn.jcghome.com.

I suppose if I made my internal domain name match the external, except for the TLD, I could use the netbios name for authentication, and it would appear to match "what they are logging into".  For example, they could log in with jcghome\username to vpn.jcghome.com, or ftp.jcghome.com... and it would make more "sense" to them.  In your experiences, does this type of thing matter at all?  Or do you just require your users to "know what to use"?

Users definitely get confused, no way around that.  They can always use the NetBIOS name for the domain e.g. int\username.  With the VPN connection it's usually not a big deal, since the IP or FQDN they're connecting to is saved with the connection, so you typically only have to enter it once.  However, the username (with the domain prepended) has to be entered repeatedly for logons to various resources like OWA, VPN, etc.  Even if you save the credentials, usually there's a password policy so that they have to change it every so often.  If I ever have to logon to a user's machine and then log out, they typically don't know how to log themselves in.  They're so used to only having to type in their password that they don't even see that the username (which is automatically filled in with the last user logged on, unless you set a group policy) is not theirs, and if they do, sometimes they can't figure out how to enter another username.  :o

Heh... Users...

Thanks for your time and insight.  I have what I need to get this going, and a better conceptual understanding as well.

John

Either solution is equal... they represent different ways of accomplishing the same basic thing.  However, EE only allows me to select one.