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 (nwoods.org and northwoods.church) are DNS hosted at DNS Made Easy. Traditionally (for nwoods.org), 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.
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
environments.
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 internal.caryalliance.org (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 caryalliance.org. 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.
@MagnaVis I’m with you on that; best practice is for AD domains to be a non-published but valid domain (internal.nwoods.org or corp.company.com for example). Unfortunately, our internal domain is nwoods.org and has been for a while. Fortunately, we are abandoning nwoods.org 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.
