Split-Brain DNS: Configuring DirectAccess for Office Communications Server (OCS)

One of the considerations for DirectAccess planning is to decide which DNS names should be resolved internally, by your organization’s internal DNS servers, and which should be resolved externally, using the traditional DNS server configured for your computer’s network interface. This distinction about which DNS server to send each query to is configured on a Windows 7 or Windows Server 2008 R2 computer using entries in the DNS Client resolver’s Name Resolution Policy Table (NRPT).

clip_image002

I won’t go into more details about the specifics of how the NRPT works here, but you can read more about the technology in this TechNet Cable Guy article.

Generally, the task of planning for NRPT entries is pretty easy, because many organizations have a DNS namespace set aside that is normally available only on the intranet – these names are obvious candidates to be referred by the DirectAccess Name Resolution Policy Table to internal DNS servers. a bit more decision-making goes into the process if your organization has a “split brain” DNS. This is a DNS arrangement where you have the same DNS domain available both externally and internally, but the internet-facing version of the DNS domain returns only addresses of public-facing resources, while the internal-facing version provides a full array of internal resource addresses. In these cases, most organizations prefer to have DirectAccess-enabled clients resolve names to the intranet DNS because it has a more fully-populated set of names – the clients will behave like they are always on the intranet.

Without split-brain DNS, there is a natural dividing line between the DNS queries that DirectAccess and the NRPT should send to internal DNS and those that should stay on the internet. But beware! If you have split-brain DNS you may need to make some special allowances for DNS queries that should stay on the internet.

But there are some services where it may be desirable to point clients differently when they are on the intranet than when they are on the internet. For example, an implementation of Outlook Web Access (OWA) may have an internal-facing deployment for web-based email browsing for users on the intranet and a different, more secure implementation for users while they are on the internet, both using the same URL such as https://owa.mycompany.net. These cases call for an exception to be made in the NRPT – essentially an entry that says, “Although I would like you to resolve all names in mycompany.net by querying our intranet DNS servers, if you want to look up owa.mycompany.net, just go to your regular interface-configured DNS server and look it up”.

The most common cases for making an NRPT exception at the customers deploying UAG DirectAccess today are for OWA, for the name of the VPN concentrator for existing VPN solutions, for external-facing Terminal Services/Citrix, and for Office Communications Server (OCS). In many cases where split-brain DNS is not involved, exceptions are not needed, because the external names are already outside the DNS domain of the internal namespace. For example, if your NRPT directs all queries for internal.mycompany.com to DNS servers on the intranet, you will not need to make an NRPT exception for OWA.mycompany.com, but you would need an exception if you wanted OWA.internal.mycompany.com to query internet DNS servers instead of internal ones while clients are internet-connected.

OCS is a special case. The current version of OCS (2007 R2) does not support connections over IPv6, not even over UAG-DirectAccess’ NAT64 function. Because all DirectAccess traffic is either end-to-end IPv6 or is client-to-UAG IPv6 and UAG-to-resource IPv4 using NAT64, OCS just does not work if the traffic is sent through the DirectAccess server.

Fortunately, most OCS deployments also have external-facing components that users can access directly on the internet. But in order for external OCS to work properly, you must define your NRPT exceptions properly, so your DirectAccess-enabled clients don’t try to resolve intranet names for your OCS components. We want them to go to the internet-facing servers while outside, even if DirectAccess blurs this distinction and makes the clients behave more like they are on the intranet.

An NRPT exception consists of a fully-qualified DNS name that has no associated DirectAccess DNS Server address. This tells the DNS client to resolve the excepted name using its normal interface-configured DNS server instead of following the more general rule and sending the query to the internal DNS server.

The example below, output from the netsh namespace show policy command on a DirectAccess-enabled client, shows an exception followed by a more general rule:

Settings for sip.mycompany.net

----------------------------------------------------------------------

Certification authority :

DNSSEC (Validation) : disabled

DNSSEC (IPsec) : disabled

DirectAccess (DNS Servers) :

DirectAccess (IPsec) : disabled

DirectAccess (Proxy Settings) : Bypass proxy

Settings for mycompany.net

----------------------------------------------------------------------

Certification authority :

DNSSEC (Validation) : disabled

DNSSEC (IPsec) : disabled

DirectAccess (DNS Servers) : 2001:db8:e0:7979::100:2

                                          2001:db8:e0:7979::100:1

DirectAccess (IPsec) : disabled

DirectAccess (Proxy Settings) : Bypass proxy

For OCS, there are a set of seven standard names that you may need to include as exceptions in a DirectAccess NRPT configuration. These are:

      _sipinternaltls._tcp.<yourdomainname>

      _sipinternal._tcp. <yourdomainname>

      _sip._tls. <yourdomainname>

      _sip._tcp. <yourdomainname>

      sip. <yourdomainname>

      sipinternal. <yourdomainname>

      sipexternal. <yourdomainname>

Additionally, there are three external DNS names that your clients need to resolve in order to locate external-facing OCS Server components. The names that are configured for your OCS Access Edge Server, Web Conferencing Edge Server, and A/V Edge Server can be set to whatever you want, so you will need to look them up in your OCS configuration’s Edge Interfaces properties as shown in the screen shot below. These DNS names are also discussed in this OCS TechNet article.

clip_image004

These items above assume that the OCS client is using the default automatic discovery mechanisms to get their configuration. It is also possible that an organization may choose to use manual configuration for the initial configuration of OCS. The specific names used in manual configuration of the connection settings can be delivered through Group Policy or be configured directly at the OCS client. You can see if there is an additional name that you might need to make an exception for in your NRPT by examining the OCS settings from the OCS options\personal\advanceddialog, like the one shown below.

clip_image005

Once you have figured out the NRPT exceptions that you need to make to suit your organization’s external-facing service names, you can set them up in the UAG DirectAccess Infrastructure Server Configuration step, like shown below.

clip_image007

Hopefully, this can help you smooth over any deployment wrinkles associated with OCS as you deploy UAG DirectAccess, and can help you understand situations where other NRPT exceptions might be needed.

Author:
Pat Telford, Principal Consultant, Microsoft Consulting Services