Howdy,

Overview

In This article I will be explaining the Lync DNS requirements

One of the critical components for Lync to work is the DNS Entries. Lync uses two kind of DNS entries:

  1. A record
  2. SRV record

The DNS is usually deployed in a “Split-brain” deployment, this mean that the same zone as the external zone is deployed internally but with different IP-address than the public routable ones.

This split brain make sure that the Lync Clients get the information only from their zone , what I mean is if it’s an external client trying to connect to Lync, it will resolve the entries to the external IP-addresses, if it’s from internal network of the infrastructure, then it will resolve the DNS entries to the internal IP-addresses using the internal DNS server.

If you are not using “Split-brain” cause it’s not possible in your infrastructure, for example you have “company-domain.local” for internal use and using the external name “company-domian.com”

You can create a zone for each required DNS records pointing it to the internal IP-address.

DNS Entries Requirement

This is a list of the required DNS records you need to create for Lync to work. I will be using my domain name but you should get the idea

Internal DNS A Records

Entry Pointing to
admin.lyncdude.net Front-end server   OR Front-end Pool
meet.lyncdude.net Front-end server   OR Front-end Pool
dialin.lyncdude.net Front-end server   OR Front-end Pool
lyncwebint.lyncdude.net Front-end server   OR Front-end Pool
sip.lyncdude.net Front-end server   OR Front-end Pool
Lyncdiscoverinternal.lyncdude.net
 Front-end server OR Front-end Pool

External DNS A Records

Entry Pointing to
meet.lyncdude.net ReverseProxy
dialin.lyncdude.net ReverseProxy
lyncwebext.lyncdude.net ReverseProxy
lyncdiscover.lyncdude.net ReverseProxy

DNS SRV records

Entry Port Pointing to
_sipinternaltls._tcp.lyncdude.net 5061 sip.lyncdude.net
_sipinternaltls._tcp.anotherdomain 5061 sip.lyncdude.net
_sipfederationtls_.tcp.lyncdude.net 5061 sip.lyncdude.net
_sip._tls.lyncdude.net 5061 sip.lyncdude.net

Discovery and Sign-in

As most of people are moving to Lync 2013 now, we need to know that unlike in Lync 2010, Lync 2013 clients favor Autodiscover services over DNS SRV records to locate the frontend server.

Auto-discover discovery process

Lync Client and Lync Mobile will attempt to resolve DNS records in the following order:

  1. Lync client will try to resolve lyncdiscoverinternal.(sip-domain) , this is an internal record so the client need to be inside the network to be able to resolve this records, if the client couldn’t resolve the record it knows it is outside the corp network and goes to step two
  2. Lync client will try to resolve lyncdiscover.(sip-domain)
  3. at this point Mobile / Windows App Lync clients will fail to login and stop trying.

DNS SRV discovery process

If those steps fail, and Lync clients couldn’t find them, then it will fall back to the DNS SRV records in the following order:

  1. Lync client will try to resolve _sipinternaltls.tcp_(sip-domain) using TLS
  2. Lync client will also try to resolve _sipinternal.tcp.(sip-domain) using TCP
  3. Lync client will also try externally to resolve _sip._tls.(sip-domain) using TLS
  4. sipinternal.(sip-domain) , internal A record of the Frontend / Director pool
  5. sip.(sip-domain) , Internal A record of the Frontend / Director pool (Internally) , or Access Edge Service (Externally)
  6. Sipexternal.(sip-domain) , A record for the external Access Edge services

NOTE: you need to understand that only the Lync Desktop clients I’m talking about them up, regarding the Lync Mobile or Windows Store app, will not fail back to DNS SRV, instead the login will be unsuccessful.

NOTE: also that, the Lync Mobile cannot download the certificate and need the Autodiscover URL to locate the Frontend, so either you can install the certificate manually on all of your mobiles (headache) or what is commonly used is making a Forward lookup from your internal DNS to external DNS so that the lyncdiscover record is resolved to the IP of your reverse proxy allowing the Lync mobile client to use the 3rd-party installed SSL certificate.

The DNS record that got resolved by the Lync Client will tell the Lync client the FQDN and port of the SIP register server (either the Lync Front end or the Director server). If you using DNS load balancing, then the client will get all the IP-address of the servers in the pool in a random way, and will try to connect to them and after registration most probably the client will be redirected to the correct front end.

If you using Hardware load balancing, the Lync Client will get the  VIP of the hardware load balancer.

NOTE: for internal traffic the Director is defined as the result of the DNS SRV query for automatic login, which then will redirect the traffic to the correct pool or server that is homing the users.