Determining DNS Requirements
Topic Last Modified: 2012-10-16
Use the following flow chart to determine Domain Name System (DNS) requirements.
Determining DNS Requirements Flow Chart
.jpg "DNS Flowchart for External User Access")
Important
The name you specify must be identical to the computer name configured on the server. By default the computer name of a computer that is not joined to a domain is a short name, not a fully qualified domain name (FQDN). Topology Builder uses FQDNs, not short names. So, you must configure a DNS suffix on the name of the computer to be deployed as an Edge Server that is not joined to a domain. Use only standard characters (including A–Z, a–z, 0–9, and hyphens) when assigning FQDNs of your Lync Servers, Edge Servers, and pools. Do not use Unicode characters or underscores. Nonstandard characters in an FQDN are often not supported by external DNS and public CAs (that is, when the FQDN must be assigned to the SN in the certificate). For details about adding a DNS suffix to a computer name, see Configure DNS Records for Edge Support.
Configuring Split-Brain DNS with Lync Server 2010
Like network address translation (NAT), the term split-brain DNS is defined several different ways. For this document, the term split-brain DNS means that the DNS zone for a given namespace is the same in the internal DNS as it is in the external DNS. However, many of the DNS SRV and A records contained in the internal DNS will not be contained in the external DNS, and the reverse is also true. And in cases where the same DNS record exists in both the internal and external DNS (for example, www.contoso.com), the IP address returned will be different, depending on where the DNS query is made.
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:
Contains a DNS zone called contoso.com for which it is authoritative
The internal contoso.com zone contains:
DNS A and SRV records for Microsoft Lync Server 2010 client autoconfiguration (optional)
DNS A or CNAME records for automatic discovery of Lync Server Web Services.
DNS A and SRV records for all internal servers running 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 contoso.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 contoso.com
External DNS:
Contains a DNS zone called contoso.com for which it is authoritative
The external contoso.com zone contains:
DNS A and SRV records for Lync Server 2010 client autoconfiguration (optional)
DNS A or CNAME records for automatic discovery of Lync Server Web Services.
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
How Clients Running Microsoft Lync 2010 Locate Services
During DNS lookup, SRV records are queried in parallel and returned in the following order to the client (if configured and available):
_sipinternaltls._tcp.<domain> - for internal TLS connections
_sipinternal._tcp. <domain> - for internal TCP connections (performed only if TCP is allowed)
_sip._tls. <domain> - for external TLS connections
_sip._tcp. <domain> - for external TCP connections (performed only if TCP is allowed)
Where <domain> is the SIP domain used by your internal clients. The last two queries are for clients that are connecting from outside your internal network. When creating SRV records, it is important to remember that they must point to a DNS A record in the same domain in which the DNS SRV record is created. For example, if the SRV record is in contoso.com, the A record it points to cannot be in fabrikam.com, it has to also be in contoso.com.
The first time you sign in, the client running Lync attempts to connect to a Front End pool using each of the three SRV records in order, regardless of whether you are signing in from inside our outside your network. After the client running Lync makes a successful connection, it caches the DNS entry and continues to use it until it is no longer successful. If the client running Lync cannot use the cached value, it queries DNS for the SRV records again and repopulates its cache. For example, this process is followed if you have signed in to the internal network during the day and then take your laptop home and sign in externally.
After the SRV record is returned, a query is performed for the DNS A record (by FQDN) of the server or Front End pool associated with the SRV record. If no records are found during the DNS SRV query, the Lync client performs an explicit lookup of sipinternal.<domain>. If the explicit lookup does not produce results, the Lync client performs a lookup for sip.<domain>.
Automatic Configuration without Split-Brain DNS
If you use split-brain DNS, a Lync Server 2010 user that signs in internally can take advantage of automatic configuration if the internal DNS zone contains a _sipinternaltls._tcp SRV record for each SIP domain in use. However, if you do not use split-brain DNS, internal automatic configuration of clients running Lync will not work unless one of the workarounds described in later in this section is implemented. This is because Lync Server 2010 requires the user’s SIP URI to match the domain of the Front End pool designated for automatic configuration. This was also the case with earlier versions of Communicator.
For example, if you have two SIP domains in use, the following DNS service (SRV) records would be required:
If a user signs in as lstest01@contoso.com the following SRV record will work for automatic configuration because the user’s SIP domain (contoso.com) matches the domain of automatic configuration Front End pool):
_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
If a user signs in as lstest01@fabrikam.com the following DNS SRV record will work for automatic configuration of the second SIP domain.
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
For comparison, if a user signs in as lstest01@litwareinc.com the following DNS SRV record will not work for automatic configuration, because the client’s SIP domain (litwareinc.com) does not match the domain that the pool is in (fabrikam.com):
_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
If automatic configuration is required for clients running Lync, select one of the following options:
Group Policy Objects Use Group Policy objects (GPOs) to populate the correct server values.
Note
This option does not enable automatic configuration, but it does automate the process of manual configuration, so if this approach is used, the SRV records associated with automatic configuration are not required.
Matching internal zone Create a zone in the internal DNS that matches the external DNS zone (for example, contoso.com) and create DNS A records corresponding to the Lync Server 2010 pool used for automatic configuration. For example, if a user is homed on pool01.contoso.net but signs into Lync as lstest01@contoso.com, create an internal DNS zone called contoso.com and inside it, create a DNS A record for pool01.contoso.com.
Pin-point internal zone If creating an entire zone in the internal DNS is not an option, you can create pin-point (that is, dedicated) zones that correspond to the SRV records that are required for automatic configuration, and populate those zones using dnscmd.exe. Dnscmd.exe is required because the DNS user interface does not support creation of pin-point zones. For example, if the SIP domain is contoso.com and you have a Front End pool called pool01 that contains two Front End Servers, you need the following pin-point zones and A records in your internal DNS:
dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com. dnscmd . /zoneadd pool01.contoso.com. /dsprimary dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90 dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91If your environment contains a second SIP domain (for example, fabrikam.com), you need the following pin-point zones and A records in your internal DNS:
dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com. dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90 dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
Note
The Front End pool FQDN appears twice, but with two different IP addresses. This is because DNS load balancing is used, but if hardware load balancing is used, there would be only a single Front End pool entry. Also, the Front End pool FQDN values change between the contoso.com example and the fabrikam.com example, but the IP addresses remain the same. This is because users signing in from either SIP domain, use the same Front End pool for automatic configuration.
For details, see the DMTF blog article, "Communicator Automatic Configuration and Split-Brain DNS," at https://go.microsoft.com/fwlink/p/?LinkId=200707.
Note
The content of each blog and its URL are subject to change without notice.
How Mobile Device Clients Running Lync 2010 Locate Services
Mobile device clients running Lync 2010 use autodiscover DNS A or CNAME records to locate mobility services. During the DNS lookup, first a connection is attempted to the fully qualified domain name (FQDN) that is associated with the internal DNS record (that is, lyncdiscoverinternal. <sipdomain>). If a connection cannot be made to the internal URL, a connection is attempted to the FQDN that is associated with the external DNS record (that is, lyncdiscover. <sipdomain>). Priority is always given to the internal URL. If a connection to the internal URL is successful, the client uses the corporate Wi-Fi network. If the connection to the internal URL is not successful, but a connection to the external URL is successful, the client request passes through the reverse proxy and is routed to the Front End Server or Director.
When a connection is successful, the Autodiscover Service returns all the Web Services URLs for the user's home pool, including the Mobility Service URLs. However, both the internal Mobility Service URL and the external Mobility Service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to the network, the device always connects to the Mobility Service externally through the reverse proxy.
Tip
Although the default configuration enables mobile client traffic to go through the external site, you can modify settings to return only the internal URL. With this configuration, users can use Lync mobile applications on their mobile devices only when they are inside the corporate network. To support this configuration, you need to run the Set-CsMcxConfiguration cmdlet. You also need to configure the internal Web Services virtual IPs (VIPs) on your Front End Server and Director hardware load balancers for cookie-based persistence. For details about hardware load balancer requirements, see the “Hardware Load Balancer Requirements for Reverse Proxy” section in Hardware Load Balancers. For details about using Set-CsMcxConfiguration to restrict mobile client traffic to the internal network, see Installing the Mobility and Autodiscover Services.
Note
Although mobile applications can also connect to other Lync Server 2010 services, such as Address Book Service, internal mobile application web requests go to the external web FQDN only for the Mobility Service. Other service requests, such as Address Book requests, do not require this configuration.
Lync 2010 for mobile devices also supports manual discovery of services. In this case, each user must configure the mobile device settings with the full internal and external Autodiscover Service URIs, including the protocol and path, as follows:
https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root for external access
https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root for internal access
Using automatic discovery, rather than manual discovery, is highly recommended. However, using manual settings is useful for troubleshooting mobile device connectivity issues.For details about the DNS records used for the Autodiscover Service, see Technical Requirements for Mobility. For details about planning for mobility, see Planning for Mobility.
DNS Load Balancing
DNS load balancing is typically implemented at the application level. The application (for example, a client running Lync 2010), tries to connect to a server in a pool by connecting to one of the IP addresses resulting from the DNS A query for the pool fully qualified domain name (FQDN).
For example, if there are three front end servers in a pool named pool01.contoso.com, the following will happen:
Clients running Lync 2010 query DNS for pool01.contoso.com and get back three IP addresses and cache them as follows (not necessarily in this order):
pool01.contoso.com 192.168.10.90
pool01.contoso.com 192.168.10.91
pool01.contoso.com 192.168.10.92
Then, the client attempts to establish a Transmission Control Protocol (TCP) connection to one of the IP addresses. If that fails, the client tries the next IP address in the cache.
If the TCP connection succeeds, the client negotiates TLS to connect to the Front End Server.
If it gets to the end without a successful connection, the user is notified that no servers running Lync Server 2010 are available at the moment.
Note
DNS-based load balancing is different from DNS round robin (DNS RR) which typically refers to load balancing by relying on DNS to provide a different order of IP addresses corresponding to the servers in a pool. Typically DNS RR only enables load distribution, but does not enable failover. For example, if the connection to the one IP address returned by the DNS A query fails, the connection fails. Therefore, DNS round robin by itself is less reliable than DNS-based load balancing. You can use DNS round robin in conjunction with DNS load balancing.
DNS load balancing is used for the following:
Load balancing server-to-server SIP and HTTP traffic
Load balancing Unified Communications Application Services (UCAS) applications such as Conferencing Auto Attendant, Response Group, and Call Park
Preventing new connections to UCAS applications (also known as "draining")
Load balancing all client-to-server traffic between clients and Edge Servers
DNS load balancing cannot be used for the following:
- Client-to-server web traffic
DNS load balancing and federated traffic:
- If multiple DNS records are returned to a DNS SRV query, the Access Edge service always picks the DNS SRV record with the lowest numeric priority and highest numeric weight. If multiple DNS SRV records with equal priority and weight are returned, the Access Edge service will pick the SRV record that came back first from the DNS server.