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:
- A record
- 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:
- 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
- Lync client will try to resolve lyncdiscover.(sip-domain)
- 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:
- Lync client will try to resolve _sipinternaltls.tcp_(sip-domain) using TLS
- Lync client will also try to resolve _sipinternal.tcp.(sip-domain) using TCP
- Lync client will also try externally to resolve _sip._tls.(sip-domain) using TLS
- sipinternal.(sip-domain) , internal A record of the Frontend / Director pool
- sip.(sip-domain) , Internal A record of the Frontend / Director pool (Internally) , or Access Edge Service (Externally)
- 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.
June 23, 2014 at 6:32 pm
Does the procedure same for Lync physical phones when it is registering from internal and external entries?
June 25, 2014 at 10:37 am
Hi Sun,
Lync Edition phones are a different Story, in a nutshell they depend on your internal DHCP server to get options 43 and 120 to locate your Frontend and download the Certificate to sign in.
check this link for more information http://technet.microsoft.com/en-us/library/gg398088(v=ocs.14).aspx
Kind Regards,
M.eltohamy
June 25, 2014 at 9:52 am
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.
December 3, 2014 at 8:37 pm
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.
December 3, 2014 at 8:48 pm
Hi JP,
already corrected. thanks a lot i dont know how did i miss that 🙂
December 9, 2014 at 3:56 pm
Greetings.
What do you mean by reverse proxy ?
December 13, 2014 at 10:31 am
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 🙂
March 3, 2015 at 1:14 pm
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!
March 3, 2015 at 4:14 pm
Nevermind.. that wouldn’t work.
July 7, 2015 at 6:46 am
hi
if i don’t have the reverse proxy, how can i point the external dns record for the public?
thanks
July 21, 2015 at 3:54 pm
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
December 8, 2015 at 5:51 am
_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?
December 8, 2015 at 5:56 am
sorry I got an answer for this. 🙂
https://technet.microsoft.com/en-us/library/bb663700%28v=office.12%29.aspx