• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2417
  • Last Modified:

External vs Internal Domain Name


We are considering changing our public domain name, and investigating the possibility of having the same or different names for the public/external domain and internal Active Directory domain. The authoritative DNS servers for the public domain and Web Servers will be hosted on our site (managed internally).

What are the advantages/disadvantages of each way? Are there any security issues, when having the same name for external and internal domain? It seems that the management is much easier in that case. I guess in order for internal users to also be able to access the servers of the public domain, a DNS zone for the public domain must also be configured on the the internal DNS servers.

Please let me know your opinion.

6 Solutions
Matt VCommented:
There are many reasons not to have the same internal and external domain name.  This separation is good from a security standpoint but also makes accessing external resources on the external domain from the internal one much easier.

The .local domains exist for many of the same reasons that the private IP subnets do.  By having a non-public domain name, you limit the mixing of the inside and outside.
I strongly recommend against using the same name for your internal and external domains. This typically causes more problems than it solves, and administration may end up being more complex rather than simpler. For example, one common issue that arises in that scenario is an externally hosted website that can't be reached by users in the office. (Searching EE will show you numerous examples of this.) Say your site is written to respond to the FQDN mydomain.com (without www or any other prefix, as is pretty common nowadays). External users can get to the site with no problem, as long as the public DNS records are configured correctly, but for internal users, mydomain.com will resolve to the IP address of one of your domain controllers. This is by design, and the only way around it is to recode the site so that it responds to www.mydomain.com, then add a www host record to your internal DNS. If the site is hosted on a shared-hosting server or cluster with multiple IP addresses that don't always remain the same, this can get nasty.

I also don't recommend using the same actual domain internally and externally (using one or more of your domain controllers as the authoritative DNS server for your external domain and making it externally accessible, in other words). You generally want to keep your internal domain as separate from the internet as you can, for security reasons.

What I recommend instead is making your internal domain a child of your external domain. If your external domain is named mydomain.com, give your internal domain a name like corp.mydomain.com. You don't have to actually make it a child domain from an external perspective; just name it that way. The two domains will still have two separate namespaces, and you'll be free to unite them in some fashion later if you choose.
I suggest this as good reading.

Personally, I wouldn't recommend managing your own public DNS servers unless you really know what you're doing.
I wouldn't provide internet access to any DNS that is AD-integrated.  So whether you choose the same name internally and externally or not, I would set up separate DNS servers that would be accessed by the internet vs. what you use internally.  In general, I think the current recommendation as best practice is to make your internal domain a subdomain of what you use externally.  So if you have an external/public domain of example.com, your internal could be corp.example.com.
We Need Your Input!

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!

Hypercat (Deb)Commented:
Just adding to DrDave242's comments.  I've set up domains both ways, and I actually don't find it to be that much of a problem to have the same internal and external domain name. However, if you're concerned about security issues and particularly if you're going to be hosting your external DNS zone on-site, I would agree with the comments about having 2 separate domain names. You will obviously need to have a firewall between your internal and external DNS zones anyway, for security purposes, so it makes a bit more sense to have 2 different domain names.  The ".local" terminology doesn't fly any more for the most part, so I agree the recommendation to use a "mydomain.com" and "corp.mydomain.com" type of naming convention.
Will SzymkowskiSenior Solution ArchitectCommented:
I also second the Public DNS comment by footech. It also makes it very challenging when you manage your own Public DNS doing DR related work.

Aaron TomoskyTechnology ConsultantCommented:
You will get a few opionions, each with their pros and cons. Here is what I do, you can decide for yourself which one you prefer.

I use something.domain.com. Sometimes it's corp.domain.com, sometimes it's i.domain.com (for internal). For multisite forests it's location.corp.domain.com. This allows you to have a public dns (not your own) for your website and all external subdomains. No duplicating ftp.domain.com or using an internal dns server publically. Because it's not a "fake" domain like .local or .lan, you can actually route it if you need to. You can also get 3rd party certs for domain controllers and other internal sites because they have real top level domains (dc.i.domain.com)

I chose this path about 4 years ago and have never regretted it.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now