With the coming of the cloud age, hosted infrastructure (Infrastructure as a Service) in Azure, infrastructure has instantly become more complex than ever. Organizations explore their options to extend their services to Microsoft Azure and Office 365. The fine line between internal and external service exposure has thinned even further. Employees often can’t even tell if services are hosted either internally or externally. Since July 2012, internal service names cannot be part of certificate subjects anymore, forcing customers to use split-brain DNS. Which leads us to our first question:
What exactly is split-brain DNS and why do I need it?
Let’s start with DNS in general. DNS is considered to be either ‘internal’ or ‘external’ to any organization. Internal DNS is usually Active Directory integrated, or represented by a network appliance. Nearly all resources for a client within the organization are domain-joined, hence considered ‘internal’.
If you host certain services that exist both internally and externally, you want to control the path clients are using to get to that service. Imagine having a local Skype for Business deployment. Your frontend pool could be something like: ‘pool.organizationxyz.com‘. This way it is resolveable externally (if published properly, duh). You would still want your internal Skype for Business clients to be able to connect to the service, but if your local domain is something else than ‘organizationxyz.com‘, this would be challenging. What would happen is that your internal clients would traverse DNS from internally to externally in order to resolve ‘organizationxyz.com‘. Once they find this record externally, they would then follow the routing from an external point of view. This results in an inefficient path where internal clients are routed externally to access your internally hosted service. Doesn’t make much sense does it? The answer is split-brain DNS. The ‘brain’ part in this technology represents ‘that which is telling the truth, don’t ask anyone else, this is the truth‘. The brain exists both internally and externally to the company. Internally, we would like it to be Windows AD-integrated DNS. Externally, it could be your hosting party. At this stage the external DNS would already be in-place (since we were able to route our internal clients externally). But now we want to create a ‘Forward Lookup Zone’ that holds our external domain name. Since internal DNS is always used before external DNS for internal clients, we are able to direct our internal clients to our internal pool IP. This is represented by the following graphic:
By using split-brain DNS we can prevent inefficient routing of clients and ensure optimal service availablity. This means the service has to be presented in an external way using the internal DNS, which brings us to the next question:
What is a ‘Pinpoint DNS’ record?
Pinpoint DNS is used for intelligent redirection of DNS requests without interrupting any of the existing services and resolution of those services. Sounds neat huh? Well it is! If by this point you are asking yourself: why haven’t I implemented split-brain DNS yet? Your answer would probably be: I’m not sure how external routing is affected by creating external DNS records internally. That’s where pinpoint DNS comes in. As a matter of fact; you don’t need pinpoint DNS records for this specific topic, but it sure helps (we’re mitigating the chance of negative side-effects, remember?). So if we assume we’re using Active Directory integrated DNS, we go on and create a new forward lookup zone as we’d normally would. However the only difference is that we’re not really creating a zone as ‘a zone’, but we give it the name of our service. So in our Skype for Business example, creatively named ‘service1’, our Forward Lookup Zone would look like:
With this zone created, we merely need to point it towards our service IP. Remember, we already estabilished the hostname part as part of our zone, so we want to create a new record within the zone, leave the name blank and enter the IP address of our service. The record would be of type ‘same as parent’ as shown below:
Now if we try to ping this service from an internal client, we’d get a reply from the 10.0.0.200 address. If we ping this service from an external client, we’d get a reply from the externally configured address. And remember, this construction pinpoints this one specific service to two IP addresses depending on your location in respects to the organization and provides you with the most efficient route towards the service.
How do conditional fowarders relate to pinpoint records?
DNS conditional forwarders are ‘catch alls’ for requests that cannot be resolved in the internal DNS. Please note though that if a client is internet-enabled, all DNS requests that cannot be resolved internally, are routed externally nontheless. In our example, service1.organizationxyz.com is rerouted internally due to our pinpoint record. However, due to the nature of DNS, if we would remove the pinpoint record, the client would still be able to resolve service1.organizationxyz.com, albeit in the external DNS. This is because of the configured internet root servers in the DNS server. Conditional forwarders are designed to be used in multi-forest on-premises environments. Imagine a merger between orgxyz.local and orgabc.local. Orgxyz clients will not be able to find any resource relying on their internal (or external) DNS in orgabc.local until the conditional forwarder is configured.
I feel the need to repeat myself here, so: having a conditional forwarder for an external domain that is configured for external pinpoint records does not break the pinpoint records. Internal DNS is, again, the truth for the internal clients. All other services hosted on the external DNS are always routable for internal clients as long as they are able to access the external DNS.
Last question: Can I combine a conditional forwarder with a root foward lookup zone?
There is a short answer to that and it is: no. You cannot create both a conditional forwarder for organizationxyz.com AND have a root forward lookup zone for organizationxyz.com. This makes little sense and is not supported. The DNS console doesn’t allow you to configure this either.
So there you have it, the possibilities of DNS are virtually endless and the nessecity of split-brain is something we all have to deal with at some stage. However with a clear understanding of DNS, it is not hard and very flexible.