Internal/External DNS Best Practices

What is your preferred or best practice for providing “split-brain” or “split horizon” DNS? Meaning, I’m working on changing our Skype for Business SIP domain to match our email addresses, and some things need to resolve to different IP addresses depending on whether the connecting device is inside or outside the network.

For example:

  • lyncdiscover needs to resolve to the external IP address of our load balancer, but lyncdiscoverinternal needs to resolve to the IP address(es) of Skype frontend servers and needs to NOT resolve externally.
  • Assorted web services need to resolve to the load balancer for external clients, but needs to resolve to the frontend servers for internal clients.

Our domains ( and are DNS hosted at DNS Made Easy. Traditionally (for, we’ve had a Primary zone in AD DNS and just update both locations for records that need to exist for both external and internal clients. I’d like to avoid needing to remember to update DNS in both areas.


1 Like

Hey Ben - we’re in the middle of figuring that stuff out right now. @smoothslash is in the trenches right now :slight_smile:

Yea, though i walk through the vally of the shadow of death I will fear no evil.

1 Like

I found a lot of great articles for dns best practices and ill drop them here as i find them again.

If you want to not handle the entire domain internally, you can always
use Pinpoint DNS Zones[1]. This is what I typically use in my customer

1 Like

I’m not one of the last harralds of valid, non-routable internal domains, am I? I believe this is generally standard practice, though if your internal domain is already the same as your external domain, it may be more trouble than it’s worth to set up differently. I dislike split DNS with a passion borderlining on hate.

My internal domain is (and alliance.local, for those keeping track- internal.caryalliance.local is an alternative I added when I intigrated our local directory with Office 365) and my external is I have had to consider some ramifications as a result. For instance, when I sync my accounts, I need to make sure the “proxyAddress” property is set on the accounts prior to syncing. All other things being equal, I feel like I deal with a lot less headache this way than running split DNS.

From there, if I needed a service to connect internally, I would use loopback rules on the firewall to point back traffic that I specifically want connecting to internal services, if I couldn’t find another way of accomplishing the task with DNS and application configurations.

+1 for Pinpoint DNS. I just found a Skype for Business DNS flowchart that mentions exactly that:

@MagnaVis I’m with you on that; best practice is for AD domains to be a non-published but valid domain ( or for example). Unfortunately, our internal domain is and has been for a while. Fortunately, we are abandoning for everything except internal services. However, on-prem Skype for Business is kind of special in that it hosts services on two different sets of ports, one for internal and one for external. It’s very specific about internal devices resolving lyncdiscoverinternal to the internal frontend server(s).

It certainly is a lot easier if Exchange and Skype for Business are hosted on Office 365, since you only do DNS discovery “externally.” Unfortunately we can’t do that until Cloud PSTN is mature.

Having a globally-unique domain is a good thing. Having one that’s not your website makes life easier.