locked
Multiple SIP domains, DNS and Certificates RRS feed

 > 

  • General discussion

  • Discussion
    Sign in to vote
    0
    Sign in to vote

    Hi

    Until recently I thought I had fairly good good control regarding Lync and external DNS and external certificates. Then a discussion with other UC professionals made me wonder what exactly best practice is when dealing with multiple SIP domains.

    Let's say we have Contoso.com (primary), Fabrikam.com and Lucerne.com.

    Initially I would believe that would require something like this:

    DNS - external Edge
    A records: sip.contoso.com / sip.fabrikam.com / sip.lucerne.com -> IP of Access Edge
    A records: webcon.contoso.com / webcon.fabrikam.com / webcon.lucerne.com -> IP of Web conf. Edge
    A records: avedge.contoso.com / avedge.fabrikam.com / avedge.lucerne.com -> IP of AV Edge

    SRV records: sip._tls.<domain>.com for contoso, fabrikam and lucerne pointing to respective sip.<domain>.com
    SRV records: sipfederationtls._tcp.<domain>.com for contoso, fabrikam and lucerne pointing to respective sip.<domain>.com

    DNS - external Reverse proxy
    A records: webext.contoso.com / webext.fabrikam.com / webext.lucerne.com -> IP external RP
    A records: meet.contoso.com / meet.fabrikam.com / meet.lucerne.com -> IP external RP
    A records: lyncdiscover.contoso.com / lyncdiscover.fabrikam.com / lyncdiscover.lucerne.com -> IP external RP

    Certificate - External Edge
    CN: sip.contoso.com
    SAN:
    sip.contoso.com / sip.fabrikam.com / sip.lucerne.com / webcon.contoso.com

    Certificate - Reverse Proxy

    CN: webext.contoso.com
    SAN:
    webext.contoso.com / webext.fabrikam.com / webext.lucerne.com
    meet.contoso.com / meet.fabrikam.com / meet.lucerne.com
    dialin.contoso.com
    lyncdiscover.contoso.com / lyncdiscover.fabrikam.com / lyncdiscover.lucerne.com

    Numerous posts in this forum and also MS technet doc indicates this is the way to go.

    Recently there was some discussion about this and the blog article Microsoft Lync Server 2010 – Mobility Services – LyncDiscover – External Configuration showed up.

    As I understand, the author suggests to use CNAME records for all but the primay sip domain A record, and also let the SRV records point only to the primary domain - potentially dramatically reducing the length of the SAN certificate.  The same method is applied to the lyncdiscover DNS records and SAN names.
    The author does not mention the meet records / SAN names, but I suppose the mechanics are the same.

    I'm uncomfortable with this strategy. For deployments with many and changing SIP domains it would certainly be a bliss, but I fear it violates both the certificate trust model and DNS RFCs and basically relies on non-strict DNS and certificate handling in the clients.

    To sum up
    1. Are there good reasons to avoid this strategy?
    2. Will it work - and are there other side effects than users having to ponder whether to OK a certificate warning?


    Thanks for all input!

    Saturday, April 21, 2012 11:03 PM

All replies

  • Discussion
    Sign in to vote
    0
    Sign in to vote

    The configuration you have outlined is correct.  The approach of using mismatched domains between the SRV and Host (A) records is now supported in Lync Server (was previously impossible with OCS) due to the added Trust Model components in the platform.

    But, not all Lync clients currently support this configuration.  For example, the Lync Phone Edition client does not and will only succesfully sign-in if the SRV record it resolves points to a Host reecord in the same domain namespace.  So to support LPE devices externally (where DHCP Option 120 is not available) then your initial approach is better.

    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    Monday, April 30, 2012 12:44 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    While it is supported, I would still not do it.  If your user is @domain.com, and their SRV record points them to an FQDN of server.domain2.com, they will get a trust warning prompt appear saying that "Lync cannot verify that the server is trusted for your sign-in address."

    I would still make sure that the SRV always points to a FQDN that is in the same namespace to avoid these popups.

    More information:

    http://blogs.technet.com/b/jenstr/archive/2011/02/10/lync-cannot-verify-that-the-server-is-trusted-for-your-sign-in-address.aspx

    MVP | MCSE:M | MCITP: Enterprise Messaging Administrator | MCTS: OCS + Voice Specialization | http://www.shudnow.net

    Wednesday, May 2, 2012 5:22 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    Agree with Elan apart from creating SRV records you should also add sip records and pool names inside the certificate in order to avoid the certificate missmatch warning while lync users connect to lync client.

    If answer is helpful, please hit the green arrow on the left, or mark as answer. Salahuddin | Blogs:http://salahuddinkhatri.wordpress.com | MCITP Microsoft Lync

    Sunday, May 20, 2012 8:30 PM