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 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 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 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
    
    

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>.

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 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 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 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:
  
  

  	Copy Code
  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

  If 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:
  
  

  	Copy Code
  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 http://go.microsoft.com/fwlink/?LinkId=200707.

Note:
The content of each blog and its URL are subject to change without notice.

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):
  
  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.