Configuring #DirectAccess for #Lync #OCS voice/video in a split DNS scenario

 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 an external (ISP) 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).

It’s recommended to use Edge Server role rather than VPN, IPSEC etc. protocols. There is an overhead and added latency when these protocols are used. The Audio/Video and media traffic is highly sensitive to latency and jitter. If you add additional encryption, it will cause delay, because it’s needed to process the traffic on client AND server side for encrypt and decrypt the data. If the traffic goes through DirectAccess network path, it can cause a long delay, jitter. Because the sensivity of A/V and media.

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.

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.

Configuring Split-Brain DNS with Lync Server 2010

If you are configuring split-brain DNS, the following internal and external zone contain a summary of the types of DNS records required in each zone. For details, see Reference Architecture.

Internal DNS:

• DNS A and SRV records for Microsoft Lync Server 2010 client auto configuration (optional)
• DNS A and SRV records for all internal servers running Microsoft Lync Server 2010 in the corporate network
• DNS A and SRV records for the Edge internal interface of each Lync Server 2010, Edge Server in the perimeter network
• DNS A records for the reverse proxy internal interface of each reverse proxy server in the perimeter network
• All Lync Server 2010 Edge Servers in the perimeter network point to the internal DNS servers for resolving queries to yourdomain.com
• All servers running Lync Server 2010 and clients running Lync 2010 in the corporate network point to the internal DNS servers for resolving queries to yourdomain.com

 External DNS:

• DNS A and SRV records for Lync 2010 client auto configuration (optional)
• DNS A and SRV records for the Edge external interface of each Lync Server 2010, Edge Server or hardware load balancer virtual IP (VIP) in the perimeter network
• DNS A records for the reverse proxy external interface of each reverse proxy server in the perimeter network

Most Lync deployments also have external-facing components that users can access directly on the internet. But in order for external Lync to work properly, you must define your NRPT exceptions properly, so your DirectAccess-enabled clients don’t try to resolve intranet names for your Lync 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.yourdomain.com

———————————————————————-

Certification authority :

DNSSEC (Validation) : disabled

DNSSEC (IPsec) : disabled

DirectAccess (DNS Servers) :

DirectAccess (IPsec) : disabled

DirectAccess (Proxy Settings) : Bypass proxy

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

Location	Type	FQDN	Maps to/Comments
External DNS	A	access.contoso.com	SIP Access Edge external interface (contoso)
External DNS	A	webcon.contoso.com	Web Conferencing Edge external interface
External DNS	A	av.contoso.com	A/V Edge external interface
External DNS	SRV	_sip._tls.contoso.com	SIP Access Edge external interface (access.contoso.com)Required for   automatic configuration of Lync 2010 clients to work externally
External DNS	SRV	_sipfederationtls._tcp.contoso.com	SIP Access Edge external interface (access.contoso.com)Required for automatic DNS discovery of federated partners known as “Allowed SIP Domain” (called enhanced federation in previous releases).

Table 1 DNS Records Required for Single Consolidated Edge Topology: Consolidated Edge 

Location	Type	FQDN	Maps to/comments
External DNS	A	lsrp.contoso.com	Used to publish Address Book Service, distribution group expansion, and conference content.
External DNS	A	dialin.contoso.com	Dial-in conferencing published externally
External DNS	A	meet.contoso.com	Conferences published externally
External DNS	A	lsweb-ext.contoso.com	Lync Server 2010 external Web Services FQDN

Table 2 DNS Records Required for Single Consolidated Edge Topology: Reverse Proxy

These DNS names are also discussed in this TechNet article.

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 exceptions made for both sip and av.

Figure 1 UAG DirectAccess Infrastructure Server Configuration

A useful tool in troubleshooting connectivity problems is Lync/OCS Remote Connectivity Analyzer which can be found here

Summarized depending on your Lync configuration, exclude all external Lync/OCS DNS records they will resolved externally

Sources:

• Determining DNS Requirements
• Defining Your Requirments for External User Access (Lync)
• Reference Architecture 1: Single Consolidated Edge
• Split-Brain DNS: Configuring DirectAccess for OCS