Understanding Lync DNS records and Autoconfiguration

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.

Author: Lyncdude

A Senior Microsoft Unified Communications Consultant with more than 9 years of experience in Microsoft Exchange and Microsoft Lync Server / Skype for Business. Egyptian guy lives and works in Frankfurt - Germany. Worked Closely with Microsoft Dubai for 3 years designing , building and supporting Exchange and Lync Infrastructures. A Microsoft Certified ITP in Lync, Exchange and also attended Microsoft Partner Primer Filed Support Engineer T1 Training for Microsoft Lync 2010.

15 thoughts on “Understanding Lync DNS records and Autoconfiguration”

  1. Lync Mobile app for Android/iPhone WILL fail back to DNS SRV records. Only the WP8 app will not try SRV and will just fail.

  2. I believe your entry: sip.lyncdude.net ReverseProxy is incorrect.
    The sip.lyncdude.net should point to the external access edge address that is stated correctly in your remarks and not the reverse proxy.

    1. the reverse proxy is a server like a TMG or an appliance like KEMP or F5 that you use to publish your infrastructure Web services like owa, Lync services or SharePoint for example 🙂

  3. Hi!
    To piggy back off of Idep’s question. Could your reverse proxy simply be your edge pool? From there I could simply port forward the traffic need for those services? Thanks in advance!

    1. Sorry sam your question is not clear, you have access to your public dns records right? You should create the required DNS for your infrastructure there

  4. _sipinternaltls.tcp._domain.com -> FE pool (host offering FQDN)

    I have 2 different FE pools, this means I need to create 2 different internal SRV records pointing to FE pools right?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s