locked
SRV records on external DNS -_sipfederationtls._tcp.domain ??? RRS feed

  • Question

  • Hi,

    I have one question regarding SRV records on public DNS server.

    Our internal domain is:  domain.local
    Our external domain is:  domain.com

    Our clients inside our domain.local network are using Communicator 2007 with autologon without any problems.


    For the EDGE server, I should create SRV records on public DNS so the external client can login:

    Which one SRV record should I create
    :
    _sipfederationtls._tcp.domain.local

    or

    _sipfederationtls._tcp.domain.com

    This is very confusing, because the OCS edge server deployment guides states:
    _sipfederationtls._tcp.<domain>, over port 5061 (where <domain> is the name of the SIP domain of your organization

    Is this our internal domain.local or external domain.com ???????????
    Thursday, March 20, 2008 5:47 PM

All replies

  • All SRV records (internal and external) need to be located in the domain that matches the SIP URI of the user.  If you have been assigning SIP URIs like user@domain.local and want autologon to work from the internet, you'll need to change the URIs to user@domain.com and publish the appropriate internal and external SRV records.

    Thursday, March 20, 2008 6:03 PM
    Moderator
  • Mike, thank you, very much for the reply. I will try this in a day or two and will post the results. I have no doubt that it will work


    Again, thanks

    Andrija
    Friday, March 21, 2008 8:20 AM
  • Mike, I would have another question.

    Regarding changing SIP URI of the user

    I would like to ask you for basic steps I need to take. So far I tried the following:

     

    I have created the _sipinternaltls._tcp.domain.local (in domain.local zone)


    and


    _sipinternaltls._tcp.domain.com(in domain.com zone ),


    both resolve to pool.domain.local


    I have configured new SIP URI of the user so they use the user@domain.com login scheme.


    I WILL (still have not) change the certificate for pool.domain.local so that it includes the domain.com as an alternate subject name?

     

    Should this be OK for internal login to work using user@domain.com scheme?

     

     

    Best regards,

     

    Andrija

    Friday, March 21, 2008 10:30 AM
  • Hi,

    I have one question regarding SRV records on public DNS server.

    Our internal domain is:  ABC.local
    Our external domain is:  XYZ.com

    Our clients inside our domain.local network are using Communicator 2007 with autologon without any problems.


    For the EDGE server, I should create SRV records on public DNS so the external client can login:

    Which one SRV record should I create
    :
    _sipfederationtls._tcp.ABC.local

    or

    _sipfederationtls._tcp.XYZ.com

    This is very confusing, because the OCS edge server deployment guides states:
    _sipfederationtls._tcp.<domain>, over port 5061 (where <domain> is the name of the SIP domain of your organization

    Is this our internal ABC.local or external XYZ.com ???????????

     

     

     

    RGDS

    SANJAY

     

    Monday, May 5, 2008 5:09 PM
  • Yes, that is typically the intended deployment scenario when using a split-DNS configuration.  Since your users probably already have a primary SMTP address matching your external domain and possibly a UPN in the same domain, they are already accustomed to that format.  Using SIP URI's that match the same format make it easy on the user to adapt to OCS authentication as well.  Just make sure you add the new SIP domain to the OCS configuration correctly, as well as certificate SANs.

     

    Monday, May 5, 2008 8:42 PM
    Moderator
  • You've already gotten the DNS info you need however it's important to note that you'll need a trusted cert (with appropriate SANs) with the external FQDN on the edge server as well

     

    Tuesday, May 6, 2008 12:43 AM
  •  

    Sorry for hijacking your thread but I'm having the same problem, and rather than fork over the money for a new certificate and potentially break other stuff, I'd prefer to work with what we have.  Can't this security feature be bypassed or could we convince the servers to trust the email domain as well as the AD domain?

     

    Just as above users state, we have email domain users@blah.com, and AD domain blah.local.  The SRV record in blah.com points to the server ocs.blah.local.  Of course this generates a trust error:

    • "Communicator was unable to locate the login server.  The DNS SRV record that exist for domain blah.com point to an invalid server ocs.blah.local which is not trusted to provide support for the domain because the server's domain is not an exact match."

    Changing the SRV record to a new FQDN within blah.com would require us to get a new certificate (from verisign, not our internal CA), and so we see the error:

    • Communicator could not connect securely to server ocs.blah.com because the certificate presented by the server did not match the expected hostname (ocs.blah.com)."

    So to reiterate my question: Any way we can work around the cross-domain issue without changing the domains we're using, without getting a new certificate, and still using TLS?  Smile

     

    Thanks!
    Joe

    Tuesday, May 6, 2008 3:36 PM
  • ***Found the answer to my question***

     

    You said this above and I just didn't get the terminology, but for others who google their way over here I'll spell it out:  When you create the self signed certificate for your OCS server, there are fields for SANs (Subject Alternate Names), where you put in as many FQDNs as you require (in my case ocs.blah.com and ocs.blah.local), and once that's installed (and you have SRV and DNS records in place) the TLS error goes away. 

     

    Here's a site that illustrates it further:

    http://fawzi.wordpress.com/2008/02/16/configuring-ocs-2007-for-dns-splitting/

     

    Joe

    • Proposed as answer by M Fawzi Tuesday, May 5, 2009 10:26 AM
    Tuesday, May 6, 2008 5:26 PM