Topic Last Modified: 2011-04-12
Use the following flow chart to determine Domain Name System (DNS) requirements.
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.
- Contains a DNS zone called contoso.com for which it is
- The internal contoso.com zone contains:
- 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
- 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
- DNS A and SRV records for Microsoft Lync Server 2010 client auto configuration (optional)
- Contains a DNS zone called contoso.com for which it is
- The external contoso.com zone contains:
- DNS A and SRV records for Lync 2010 client auto configuration
- 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
- DNS A and SRV records for Lync 2010 client auto configuration (optional)
How Lync 2010 Clients Locate Services
During DNS lookup, SRV records are queried in parallel and returned in the following order to the client:
_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
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 Lync client 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 Lync client makes a successful connection, it caches the DNS entry and continues to use it until it is no longer successful. If the Lync client 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 Lync clients 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 email@example.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 firstname.lastname@example.org the following DNS
SRV record will work for automatic configuration of the second SIP
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
For comparison, if a user signs in as email@example.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 Lync clients, 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
firstname.lastname@example.org, create an internal DNS zone called
contoso.com and inside it, create a DNS A record for
- 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
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.91
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
|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 http://go.microsoft.com/fwlink/?LinkId=200707.
|The content of each blog and its URL are subject to change without notice.|
DNS Load Balancing
DNS load balancing is typically implemented at the application level. The application (for example, a Lync 2010 client), 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:
- The Lync 2010 client will query DNS for pool01.contoso.com and
get back three IP addresses and cache them as follows (not
necessarily in this order):
- 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.
|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
- Load balancing all client-to-server traffic between clients and
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