Lync 2013 - DNS Settings

55 Replies

If you are setting up Lync Server for the first time or have been running Lync Server, you will notice that Lync depends heavily on DNS records.  In many cases, a Lync deployment cannot be setup correctly without using a split-dns setup and using a masked UPN; which can make things even more tricky.  Here is a complete listing of DNS records I used to deploy Lync 2013.  I have verifed federation works properly, IMs, conferencing, dial-in meetings, mobile and desktop client sign-in, and desk phones.  Note, records indicated in Red are records that are required/standard in every lync deployment.

Internal DNS Records

Record Type Value Points to
A lyncdiscoverinternal.mydomain.com Lync front end server
A lyncdiscover.mydomain.com Lync reverse proxy
(needed for mobile devices to work interally)
A lync.mydomain.com Lync front end server
A sip.mydomain.com Lync front end server
(multiple A records if enterprise pool)
A dialin.mydomain.com Lync front end server
A meet.mydomain.com Lync front end server
SRV _ntp._udp.mydomain.com Domain Controller/Time Server
SRV _sip._tls.mydomain.com sip.mydomain.com
SRV _xmpp-server._tcp.mydomain.com sip.mydomain.com
SRV _sipinternaltls.mydomain.com sip.mydomain.com
SRV _sipfederationtls.mydomain.com sip.mydomain.com

**Note, you should have A records for all of the hosts in your Lync deployment (front end servers, pools, proxies, etc.).  Those are not covered in the list as they are 100% user defined when deploying Lync.

External DNS Records

Record Type Value Points to
A webconf.mydomain.com Edge server IP as specified in setup wizard
A av.mydomain.com Edge server IP as specified in setup wizard
A sip.mydomain.com Edge server IP as specified in setup wizard
A meet.mydomain.com Lync Reverse Proxy IP
A dialin.mydomain.com Lync Reverse Proxy  IP
A lync.mydomain.com Lync Reverse Proxy IP
A lyncdiscover.mydomain.com Lync Reverse Proxy IP
SRV _sip._tls.mydomain.com sip.mydomain.com
SRV _sipfederationtls._tcp.mydomain.com sip.mydomain.com
SRV _xmpp-server._tcp.mydomain.com sip.mydomain.com

 

55 thoughts on “Lync 2013 - DNS Settings”

  1. Greg

    Hello Jack,

    Why do you point sip, meet and dialin to the Reverse Proxy internally?

    Shouldn't this end up to the Frontend(pool)?

    Reply ↓
    1. Jack Post author

      Hi Greg,

      Sorry about the delay! I believe I did this for support in using Lync mobility features. I could be wrong in that they should point to the frontend pool, but I believe I ran into issues with mobile clients connecting.

      Jack

      Reply ↓
      1. Jack Post author

        Just as a follow up, Greg is correct in that the records should be referencing the front end servers/pool directly. I have updated the page to reflect the changes.

        Jack

        Reply ↓
      2. Jamie

        Based on the technet article published above. Reason for this is to your point, is that mobility devices only look for lyncdiscover.domain.suffix and require edge, so in the event a user is on the internal wifi, they route out to the internet, to the edge, and back in BY DESIGN.

        Reply ↓
    3. Daniel

      lyncdiscover.sipdomain.com and lyncdiscoverinternal.sipdomain.com should both exist in internal DNS while only lyncdiscover.sipdomain.com should exist on external DNS. Also to mention as some of us make the mistake a lot and then have issue with lync mobile connection, lyncdiscover IP should be the reverse proxy IP while lyncdiscoverinternal should be frontend server IP. Another thing is that lyncdiscover.sipdomain.com and lyncdiscoverinternal.sipdomain.com should be on the ssl certificate for the ARR IIS access.

      Reply ↓
  3. Devin

    Hi Jack,

    Great site, thanks for your help. I've been struggling with getting Lync set up for several weeks. I've got everything working but Mobile. I'm going back to the beginning and verifying my DNS.

    Regarding the SRV records that you have marked for Internal. You point them toward the sip.mydomain.com. That address though then points toward the Reverse Proxy? I thought that they would point toward the Front-End server, especially the sipinternal entry.

    Also, am I correct in assuming the DNS entries for sip, meet, & dialin point to the internal address on the Reverse Proxy server?

    Thanks so much,
    Devin

    Reply ↓
    1. Jack Post author

      Hey Devin,

      I did a little tweaking in my environment and have updated the DNS settings here to what I have currently deployed. The new settings make much more sense as we are referencing the front end pool/servers directly rather than having the extra hop to the reverse proxy. When referencing the reverse proxy, you are correct in that you can use the internal IP address.

      Please let me know how it goes!
      Jack

      Reply ↓
      1. Devin

        Hi Jack, thanks for your quick reply. Those new setting work great for my basic setup. I'm still broken with regards to mobility. I'm fairly certain I've got something broken in regards to my certificate config.

        Back to the drawing board!
        Thanks again,
        Devin

        Reply ↓
        1. Jack Post author

          Are you using a Windows Phone by chance? We have noticed that Windows Phones don't work internally with the DNS configuration above, but all other mobile devices do. What's weird though is the windows phones and all others work externally flawless. The only other thing I can think of is have you trusted your own certificates internally on the mobile devices? You will need to make sure your internal certs have been trusted in the mobile device's trusted CA store.

          Last, try going to https://testconnectivity.microsoft.com/ and running the Lync Autodiscover Web Service Remote Connectivity Test on the Lync tab. See if you are getting any certificate errors there.

          Reply ↓
          1. Devin

            Right, my team have all three phone types (WP, iPhone, & Android). Though I'm mainly using that testconnectivity site you mentioned for my testing and getting the same error. All attempts result in:

            A Web exception occurred because an HTTP 502 - BadGateway response was received from IIS7.

            From everything I've read that indicates a certificate error. (to be honest, I am a total rookie when it comes to certs) I've tried all sorts of combinations, with a wildcard cert everywhere I had everything working except mobility. Wildcards are not supported everywhere so I ordered a public cert for my reverse proxy and have tried using internal CA certs on the other servers but get the same error.

            So I don't repeat everything, I actually have a thread going on the official Lync forums .

            Thanks for your help, I really appreciate it!

          2. Jack Post author

            Hey Devin,

            I was looking at your external reverse proxy (based on the link in the technet article), and it looks like your external cert is setup correctly. I would narrow this down to internal routing between the reverse proxy and your internal lync front end server/pool. I sent you an email, let me know if you would like to look at the settings together to see if we can narrow down the problem further.

            Jack

          3. Hamish

            Hi Guys,
            I had issues with corporate wifi and mobility clients not swapping between this and their normal phone provider.
            This is because they need to hairpin back to the Reverse Proxy via the lyncdiscover DNS record.
            So if your corp wifi is supplying DNS from your internal DNS servers to the mobile clients when they swtich to wifi, you need an entry on your internal DNS pointing to your reverse proxy address for lyncdiscover.
            Won't work properly otherwise. 🙂

            Cheers,

            Hamish

    1. Jack Post author

      Hey Niles,

      It sounds like when you were deploying your Lync Standard Server in the topology builder, you may have entered your actual domain and not the UPN. I believe the step is called "Define the primary domain" where you want to enter in the UPN suffix (@domain.net) instead of @domain.local. Definitely would agree the wizard is not very clear on that step.

      Luckily, you can easily change this through the topology builder on your front end server. Simply open up topology builder, download a copy of the latest configuration from the central management store, and then right click on "Lync Server" and select Properties. On the "Edit Properties" window, you should see a field at the very top called "Default SIP domain". Enter in mydomain.net instead of mydomain.local and hit OK. Publish your topology and the changes should reflect yourdomain.net instead of yourdomain.local

      Please let me know how it goes!
      Jack

      Reply ↓
    1. Jack Post author

      Hi Ken,

      Many of the external web services will take advantage of this. When the lync client does an auto discover, it will pull down an XML file that will contain certain information pointing to which addresses the client should communicate to.

      You can find more about this from Microsoft here: http://technet.microsoft.com/en-us/library/gg398069.aspx

      Or better yet, from here: http://blog.schertz.name/2012/07/lync-edge-server-best-practices/

      Hope this helps!
      Jack

      Reply ↓
  6. Daimian WIlliams

    Hi Jack,

    really useful guide, was just wondering if you could explain one thing to me?

    I am new with the Lync product (lets say 3 days). Got my head round most of it, however on your guide, you have the internal DNS records, that should be inserted on the internal DNS. Should these be internal DNS name (domain.local etc) rather than external DNS name (domain.com).

    If external domain, I dont have a zone for our external domain created in our internal DNS, as this is handled at ISP level.

    Thank you again!

    Reply ↓
    1. Jack Post author

      Hi Daimian,

      Good question! You do not have to use a .local domain name. If your Active Directory domain is mydomain.com, you can still point lync.mydomain.com (for example) to your internal Lync server. Then, have your ISP point lync.mydomain.com to your Lync edge server if you will be allowing external access to Lync. I usually like to deploy Active Directory with a .local domain to help differentiate internal servers from external like this, but it is not required.

      Hope this helps!
      Jack

      Reply ↓
  7. mehran

    Dear Friend
    Thank you for your very valuable guidances on Lync they are wonderful and very comprehensive.

    We faced an strange problem after Lync 2013 fully implementation, would you give us any issue to solve this problems
    1- Whiteboard works about 30 minutes each time after Lync server restarting, for internal and external user both, and after that, it stops and give an error says “An error occurred while presenting”
    2- Totally we face “An error occurred while presenting” by PowerPoint sharing
    3- The call communication among two users that are both outside of domain is possible but the same call communication among a user inside domain and one outside of domain could be established , we added the user outside of domain the certificate and also in host etc, relevant IPs is added.
    We are in desperate need of a solution or guidance for this problem.

    Mehran

    Reply ↓
  8. Wes

    Awesome post, thanks! It got me all the way up to getting mobile devices to work (which is the last piece to my puzzle). Neither iOS or Android can't sign in internally or externally. I'm stuck!

    Reply ↓
    1. Jack Post author

      Hi Wes,

      Have you configured a reverse proxy yet? That is needed for the mobile clients to connect properly.

      Hope this helps,
      Jack

      Reply ↓
      1. Wes

        Thanks for getting back to me. Yep, I sure have. I have a 2012 R2 machine with IIS ARR running as my RP machine. I have to URL rewrite rules set for lyncdiscover, meet, dial and webext. They're also set for regular experssions (.*) The Lync Connectivity Analyzer comes back clean for lyncdiscover HTTPS external access. UCWA completed successfully as well too.

        Reply ↓
        1. Jack Post author

          Hmm not sure. One of the easier tests is to ensure external connectivity works first. I found this was easier to achieve as it uses a publically trusted certificate, rather than internal one issued by my PKI environment, so my devices will communicate without having to manually import/trust my root CA certificate.

          Additionally, before technet had released an article to use IIS, I followed this guide using apache as the reverse proxy. Not sure if what you are seeing is a rule or routing issue in your environment, but I do know this guide works: http://www.lynclog.com/2012/09/configuring-apache-as-reverse-proxy-for.html Maybe it will spark some ideas on what else may need to be configured to get things working in the IIS environment.

          Hope this helps!
          Jack

          Reply ↓
  9. Bikram

    Hi,

    it would have been great if... Port numbers were also mentioned along with it and dummy IP's External and Internal would have been mentioned... creating Records and Rules would have been breeze...

    thanks..

    Reply ↓
    1. Jack Post author

      Port numbers and IPs can get dicey. Some organizations require one-off scenarios and then getting support comments from them can be very difficult to help without knowing what they have done. Here I know these DNS records are going to be consistent throughout all Lync deployments.

      Reply ↓
  10. Madhu

    Hi,

    First of all i would like to appreciate you for this very simple and useful post.

    We have deployed Lync 2013 recently and it is working fine. Now we want to implement Edge services.

    But my doubt is : Our internal and external domain names are different then it is possible to implement these Edge services.

    Internal mail ID is like : [email protected] and
    external ID is like : [email protected]

    Can i be able to login to Lync using my external mail ID.

    Please let me know the process and Thanks in advance.

    Reply ↓
    1. Jack Post author

      Hi Madhu,

      You can do this. Inside of the topology builder, just make sure your set your SIP domain to be that of your external ID, not your internal. You can deploy resources like your lync front end pool (if enterprise) using the internal SIP domain, while external resources such as meat, dialin, sip can be with your external ID.

      Hope this helps,
      Jack

      Reply ↓
  11. TCat

    When I send a lync meeting to an external contact, it send my internal address. For example my internal address is meet.domaincorp.com and my external is meet.domain.com. It sends out the internal, so, obviously, when you click the link, it doesn't work. I tried to manually change it on the external side and just remove the corp at the end, but that doesn't work. Any help you can provide would be great. I do have the edge server setup. It is working if I install the lync client on the external computer. However, this one particular external user has a mac, so I can't install the client. I just want him to be able to use the link to connect.

    I have my default sip domain as domaincorp.com, but I setup simple urls for meet.domaincorp.com and meet.domain.com. I also set the "additional supported SIP domains" to have the domain.com. Is that correct?

    Reply ↓
    1. Jack Post author

      If you are using an internal PKI environment, make sure that your certificate chain is imported into the Mac's keystore.

      Additionally, if you are receiving the incorrect meeting URL, please make sure you configured this properly inside of the topology builder.

      Hope this helps,
      Jack

      Reply ↓
  12. Rasheedah

    Hi nice article and very much appreciated. Quick question when you say for example lyncdiscover should be internal dns and reverse proxy I assume the ip for that A record should be the RP internal nic, correct?

    thanks

    Reply ↓
  13. Bashir Dashti

    HI, Jack , can u give me suggestion how to solve this ,

    Testing remote connectivity to Microsoft Lync server through the Lync Access Edge server mydomain.com on port 5061 to verify user [email protected] can connect remotely.
    Specified remote connectivity test(s) to Microsoft Lync server failed. See details below for specific failure reasons.

    Additional Details

    Elapsed Time: 8745 ms.

    Test Steps

    Attempting to resolve the host name mydomain.com in DNS.
    The host name resolved successfully.

    Additional Details

    IP addresses returned: 139.1.3.20
    Elapsed Time: 165 ms.
    Testing TCP port 5061 on host mydomain.com to ensure it's listening and open.
    The port was opened successfully.

    Additional Details

    Elapsed Time: 1111 ms.
    Testing the SSL certificate to make sure it's valid.
    The SSL certificate failed one or more certificate validation checks.

    Additional Details

    Elapsed Time: 7468 ms.

    Test Steps

    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server mydomain.com on port 5061.
    The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.

    Additional Details

    Remote Certificate Subject: CN=sip.mydomain.com, OU=netlync, O=mgc, L=oman, S=nite, C=OM, Issuer: CN=mydomain-DC-CA, DC=mydomain, DC=com.
    Elapsed Time: 7446 ms.
    Validating the certificate name.
    Certificate name validation failed.
    Tell me more about this issue and how to resolve it

    Additional Details

    Host name mydomain.com doesn't match any name found on the server certificate CN=sip.mydomain.com, OU=netlync, O=mgc, L=oman, S=nite, C=OM.
    Elapsed Time: 0 ms.

    Reply ↓
    1. Jack Post author

      Hi Bashir,

      The SSL Certificate on your external edge server is invalid. I'd recommend replacing the SSL Certificate with one issued from a public certificate authority (GoDaddy, VeriSign, etc.)

      Hope this helps,
      Jack

      Reply ↓
  14. Rasheedah

    Hi Again,

    Regarding internal dns records if you have a disparate dns say dominan.local and external domain.com
    I assume you need to create a zone internally for domain.com and create those records pointing to the FE pool/server correct? Records like the dialin and meet. Thanks!

    Reply ↓

  16. Pingback: Guide: NGINX Reverse Proxy for Lync 2013 - Mike's Blog

  17. Josh

    Little confused. What are we referring to when we say "sip.domain.com" is that the actual URL or should I be replacing SIP with something else?

    Thanks great post!

    Reply ↓
  18. Raechel

    We're having an issue with external clients signing in. Currently, our external DNS records for autodiscover, meet, and dialin all point to the External Web Services FQDN (we do not have a reverse proxy). However, one of my colleagues put an entry in his host file pointing lyncdiscover to the external IP address of our Edge Server. So, my question is, if we do not have a reverse proxy, what should we be pointing our external DNS records to, specifically for autodiscover?

    Reply ↓
    1. Jack Post author

      Hi Raechel,

      You will want a reverse proxy, it is a key component in the Lync deployment (I have a tutorial on my site on how to configure this, you just need a simple IIS machine). If you are not going to use the reverse proxy (which is not recommended and a security risk), you would point the records to the Front End servers.

      Jack

      Reply ↓
  19. John

    Hi jack,
    pls what does the SIP stands for. is it my front end server or front end server pool and if i do have a director in my domain, will my SIP change or not.

    Reply ↓
  20. MTayal

    Hello Jack, As per your blog Lyncdiscover (internal DNS record) should point to Internal NIC of reverse Proxy

    In case we have 2 Revese Proxies within Load balancer (within F5 load balancer), to which Reverse Proxy we will point as there are two, or there should be a VIP on internal interface by combining two RP's

    Reply ↓
    1. Jack Post author

      I'd point to the VIP on your F5 load balancer then to ensure you don't have a single point of failure to one proxy.

      Reply ↓

Leave a Reply

Your email address will not be published. Required fields are marked *