Like network address translation, the term split-brain DNS is defined several different ways. For this document, the term split-brain DNS means the following (using contoso.com as an example):

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 all Communications Server 2010 servers in the corporate network
    
    
  • DNS A and SRV records for the Edge internal interface of each Communications 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 Communications Server 2010 servers in the perimeter network point to the internal DNS servers for resolving queries to contoso.com
  
  
• All Communications Server 2010 servers and clients running Microsoft Communicator "14" 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:
  
  
  1. DNS A and SRV records for Communicator "14" client auto configuration (optional)
     
     
  2. DNS A and SRV records for the Edge external interface of each Communications Server 2010 Edge Server in the perimeter network
     
     
  3. DNS A records for the reverse proxy external interface of each reverse proxy server in the perimeter network
     
     

If split-brain DNS is used, then automatic configuration of the Communicator "14" client will work fine as long as the _sipinternaltls._tcp SRV record is created in the external DNS contoso.com zone. However, if split-brain DNS is not in use then client automatic configuration will not work unless one of the workarounds described below is implemented. This is because Communicator "14" requires that the domain of the target host match the domain of the user’s SIP URI. This was also the case with earlier versions of Office Communicator.

For example, if a user signs in as cstest01@contoso.com the first SRV record will work for automatic configuration as follows:

_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 sip.contoso.com

However, this record will not be used by Communicator for automatic configuration even though it is a valid SRV record because the client’s SIP domain is contoso.com, not litwareinc.com.

_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 sip.litwareinc.com.

If automatic configuration is required for Communicator clients, select one of the following options:

• Put host records on each client machine.
  
  
• Use Group Policy objects (GPOs) to populate the correct server values (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).
  
  
• Create a .com zone in the internal DNS that matches the external DNS zone and create DNS A records corresponding to the Communications Server 2010 pool used for automatic configuration. For example, if a user is homed on pool01.contoso.net but signs into Communicator as cstest01@contoso.com, create an internal DNS zone called contoso.com and inside it, create a DNS A record for pool01.contoso.com.
  
  
• If you are creating an entire zone in the internal DNS is not an option, you can create dedicated zones that correspond to the SRV records that are required for automatic configuration, and populate those zones using dnscmd.exe as follows:
  
  

  dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
  
  dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 access.contoso.com.
  
  dnscmd . /zoneadd access.contoso.com. /dsprimary
  
  dnscmd . /recordadd access.contoso.com. @ A 192.168.10.90
  
  dnscmd . /recordadd access.contoso.com. @ A 192.168.10.91

  For details, see http://blogs.technet.com/b/dougl/archive/2009/06/12/communicator-automatic-configuration-and-split-brain-dns.aspx.
  
  

DNS load balancing is typically implemented at the application level. The application, (for example, an Communicator "14" client or SIP server), 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 FQDN.

For example, if there are three front end servers in a pool named pool01.contoso.com, the following will happen:

• The Communicator "14" client will query DNS for pool01.contoso.com and get back three IP addresses (not necessarily in this order), and cache them as follows:
  
  

  pool01.contoso.com      192.168.10.90

  pool01.contoso.com      192.168.10.91

  pool01.contoso.com      192.168.10.92

• Then the client will attempt to establish a TCP connection to one of the IP addresses in its cache using a TCP SYN request; if that fails, the client will try the next IP address in its cache
  
  
• If the TCP SYN request succeeds; the client will attempt to connect to the front end server a SIP REGISTER
  
  
• If the SIP REGISTER attempt fails (for example, a SIP XXX error is returned), the client has intelligence built in to try each subsequent IP address in its cache
  
  
• If it gets to the end without a successful connection, the user is notified that no Communications Server 2010 servers are available at the moment
  
  

DNS Load Balancing is used for the following:

• Load balancing Communications Server SIP servers such as Communications Server Registrar, Director and Access Edge
  
  
• Load balancing UCAS applications such as Conferencing Auto Attendant, Response Group, and Call Park Server
  
  
• Draining of Unified Communications Application Services (UCAS) applications
  
  
• Load balancing server-to-server (as well as client-to-server) connections for SIP traffic
  
  
• Load balancing client to Web Conferencing Edge traffic
  
  
• Load balancing other HTTP(s) traffic between Communications Server servers (such as Focus – conferencing servers)
  
  

DNS Load Balancing cannot be used for:

• DCOM traffic
  
  
• Client-to-server Web 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 numerical priority and highest numerical 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.