Solved

reappearing event logs - cannot resolve DNS sip.domain.com, sipinternal.domain.com

Posted on 2008-10-28
13
5,781 Views
Last Modified: 2013-11-29
We are getting the following Applicaiton error inconsistently but frequently appearing in computers using OCS.

Communicator was unable to resolve the DNS hostname of the login server sip.domain.local.
 
 Resolution:
 If you are using manual configuration for Communicator, please check that the server name is typed correctly and in full.  If you are using automatic configuration, the network administrator will need to double-check the DNS A record configuration for sip.northland.ac.nz because it could not be resolved.


It seems to appear in all computers I've checked with Communicator installed, but the dates of the error is not consistent between one computer and another nor the dates / times consistent on the same computer.
It also appears with server sipinternal.domain.local.

As far as we can tell our internal and external DNS records are correct and all Communicator, Live Meeting functionality is working correctly
0
Comment
Question by:northtecicts
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 4
  • 2
13 Comments
 
LVL 12

Expert Comment

by:gaanthony
ID: 22828521
The issue is probably that the _sipinternaltls._tcp.<domainA.com> record in internal DNS has the host offering this service as an FQDN that is servername.<domainB.com>.
For automatic configuration Communicator uses the domain information to the rightside of the @ in the users sip URI.
If sip URI is userid@mydomain.com  then there should be a DNS zone called mydomain.com with the SRV record _sipinternaltls._tcp.mydomain.com, an 'A' record in mydomain.com for sip.mydomain.com that points to the IP of the Pool on port 5061.
If your OCS server FQDN is OCS.mydomain.local then the OCS cert would have a subject name of ocs.mydomain.local and a SAN with sip.mydomain.com and ocs.mydomain.local.
On the client disable the setting on advanced TCP/IP settings: append these DNS suffixes.

http://www.ietf.org/rfc/rfc3263.txt
RFC 2543 will look up the SRV records for the domain directly. If these do not exist because the NAPTR replacement points to a different domain, the client will fail. For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior or the result of an attack
0
 

Author Comment

by:northtecicts
ID: 22836705
Thanks for the help gaanthony - if the problem was as you described would all OCS functionality still work despite the errors?


We only have one domain (DomainA.com), but we also have an alias used in DNS (mainly just used for our external website = domainB.com) due to an organisation public name change. However we have not changed our original domain name and in OCS have kept all references to this original domain name = DomainA.com(as far as I know OCS doesn't currently support multiple domain alias's).

I also forgot to mention we are using Enterprise Edition so have a pool for our front end.
Our front end server SIP IP uses port 5060 for TCP and 5061 for MTLS
It has a certificate with
SN= OCSPool.DomainA.com
SAN= sipinternal.DomainA.com
       = OCSPool.DomainA.com


in DNS forward lookup zone DomainA.com ;

_sipinternaltls._tcp.DomainA.com record in internal DNS is referencing host sipinternal.DomainA.com on port 5061
we also have _sipfederationtls._tcp.DomainA.com record in internal DNS referencing host sipinternal.DomainA.com on port 5061

_sip._tls.DomainA.com record in internal DNS is referencing host sipinternal.DomainA.com on port 5061

we have an A record of sip.DomainA.com pointing to our external SIP IP address,
an A record of sipinternal.DomainA.com pointing to our internal OCS front end IP address,
an A record of OCSpool.DomainA.com also pointing to our internal OCS front end IP address.


Do any of the above configs stand out as culprits for the error?

I've also changed my Advanced connection settings from Auto Config to Manual Config, using TLS with
Internal Server Name: OCSpool.DomainA.com
External Server Name: sip.DomainA.com

I can sign in both internally and externally with this manual config.

Thanks
0
 
LVL 12

Expert Comment

by:gaanthony
ID: 22857741
The thing to think about is if you use manual config the Communicator client does no DNS lookup beyond the FQDNs specified for internal and external server. Communicator also doesn't know whether it's connected to you internal network or external to your network.  
Keeping this in mind with manual configuration it first tries to resolve the internal FQDN.  If the client is external of course it will fail and flag that error in the event log.
When Communicator is configured for autoconfiguration then it queries first for SRV records in the following order.
Note: replace <sipdomain> with the domain information from the right hand side the the user's sip URI.
_sipinternaltls._tcp.<sipdomain>  (put in internal DNS only)
_sip._tls.<sipdomain> (put in external DNS only)
If no SRV record is found then the fall-back is to look for standard DNS name records in the following order:
sipinternal.<sipdomain>
sip.<sipdomain>
sipexternal.<sipdomain>
So when Communicator doesn't resolve a host record as it moves through the order an event will be logged it logging is enabled.
Also OCS supports multiple sip domains.  Say you have different companies under a parent company so you have different e-mail domain for each company.
You may have a DNS zone for CompanyA and CompanyB with email address of user@companyA.com and user@companyB.com.  Say you want the sip URI to match the email name convention.
Now you also have another DNS zone for your internal network called corporate.local that your OCS servers are installed in.
So the OCS pool fqdn could be pool.corporate.local.  For the Front End server cert if you have pool.corporate.local as the subject name and subject alternative name starting with the pool fqdn, the server fqdn, and then an entry for each additional sip domain - sip.companyA.com, and sip.companyB.com
For manual client configuration you could specify pool.corporate.local as the internal server and we can connect as Communicator does no sip URI domain matching to the manual configuration.  The only check is with the TLS connection that pool.corporate.local is on the OCS cert.
Now for autoconfiguration.
user@companyA.com signs in to Communicator.
DNS is queried for  _sipinternaltls._tcp.companyA.com.  If found Communicator now knows it is internal and a check is performed to verify that the host offereing this service (in my example sip.companyA.com) matches on the domain portion.  Otherwords I can't have this record as pool.corporate.local as it doesn't match.  I can create an additional DNS host record for sip.companyA.com that points to the IP address of the pool and I have sip.companyA.com listed on the OCS pool certificate's SAN so OCS will authenticate my client.
If not found DNS is queried next for _sip._tls.companyA.com.  If found Communicator now knows it is external provided you didn't put this record in internal DNS by mistake.  A check is performed to verify that the host offereing this service (in my example sip.companyA.com) matches on the domain portion.  I have an external DNS record of sip.companyA.com  that points to the IP address of the OCS Access Edge External interface. So the Access Edge external public cert will include a SAN entry for sip.companyA.com.
If not found then Communicator falls to the host records in the order specified above.
Why an SRV.  SRV are service locator records.  Communicator defaults to port 5061 unless you specify a different port via manual config or listening port in the SRV records.  This is particularly important when the Access Edge port configuration for remote users is 443.  You'll need an SRV record in external DNS.
The remote user port can be changed to 5061 to eliminate the need for an external SRV record but remote users could on other networks where 5061 is blocked but 443 isn't.
For a companyB user signing in to Communicator the process would be the same but we'd have the appropriate records in a DNS forward zone named companyB in split DNS along with the sip.companyB.com listed in the SANs of the cert on the pool and on the Access Edge external interface.
_sipfederationtls._tcp.<domain.com> is used by the Access Edge servers for automatic federation with other companies that have OCS installed.  That way you don't have to manually specify their edge server fqdn and vice versa in the Edge configurations.
============================
So to answer your specific questions
I also forgot to mention we are using Enterprise Edition so have a pool for our front end.
Our front end server SIP IP uses port 5060 for TCP and 5061 for MTLS
It has a certificate with
SN= OCSPool.DomainA.com
SAN= sipinternal.DomainA.com
       = OCSPool.DomainA.com


This is good. _sipinternaltls._tcp.DomainA.com record in internal DNS is referencing host sipinternal.DomainA.com on port 5061
Remove as this is an external DNS record for federation.  we also have _sipfederationtls._tcp.DomainA.com record in internal DNS referencing host sipinternal.DomainA.com on port 5061

Remove as this is an external DNS SRV record.  _sip._tls.DomainA.com record in internal DNS is referencing host sipinternal.DomainA.com on port 5061. You'd put this in external TLS with host offering this service as sip.DomainA.com

Good - we have an A record of sip.DomainA.com pointing to our external SIP IP address,
an A record of sipinternal.DomainA.com pointing to our internal OCS front end IP address,
an A record of OCSpool.DomainA.com also pointing to our internal OCS front end IP address.


0
The Ultimate Checklist to Optimize Your Website

Websites are getting bigger and complicated by the day. Video, images, custom fonts are all great for showcasing your product/service. But the price to pay in terms of reduced page load times and ultimately, decreased sales, can lead to some difficult decisions about what to cut.

 

Author Comment

by:northtecicts
ID: 22880036
Thanks gaanthony
I removed the two entries yesterday but the two errors continue to appear on client(s) today..

I've also found this error:
***
Communicator was unable to locate the login server.  No DNS SRV records exist for domain northland.ac.nz, so Communicator was unable to login.
 
 Resolution:
 Please double-check the server name to make sure that it is typed correctly.  If it is correct, the network administrator will either need to use manual configuration to specify the login server's fully-qualified domain name (FQDN), or add DNS SRV records for the northland.ac.nz domain in order to allow automatic client configuration.  The DNS SRV records _sipinternaltls._tcp.northland.ac.nz, _sipinternal._tcp.northland.ac.nz and/or _sip._tls.northland.ac.nz may need to be configured if automatic configuration is desired.
***


Any other suggestions of what else we could change?

Do you think it may be some problem other than OCS configuration?
0
 
LVL 12

Expert Comment

by:gaanthony
ID: 22901921
Let me ask this.   Is your communicator sign-in address like username@northland.ac.nz?
You say manually specifying the server information Communicator works but autoconfiguration does not work?
If so then in your internal DNS you need the following SRV record for client autoconfiguration.
_sipinternaltls._tcp.northland.ac.nz that points to <poolname>.northland.ac.nz on port 5061.  There should be a host record for <poolname>.northland.ac.nz and the Subject name of the OCS cert on the Home server should be <poolname>.northland.ac.nz or if the FQDN of the Home server is different then the SAN on the cert should have sip.northland.ac.nz and there be a host record for sip.northland.ac.nz that points to the IP address of the Pool.
I feel like I'm repeating myself about the client autoconfiguration setup and it  may be that I'm not asking the right question or getting all the information necessary to resolve your problem.  I really want to help.
I recommend the following:
Download and run the OCS Best Practices Analyzer and resolve any issues identified.
http://www.microsoft.com/downloads/details.aspx?FamilyID=1b90993c-072a-4c84-b385-b76d23b2f27c&displaylang=en
You should also run the Validation wizards on your Home server and Edge server for each role with only the first two options checked and then resolve any errors.  Most warnings can be ignored and should be explanatory.
 
0
 
LVL 1

Expert Comment

by:Dresdner
ID: 22913977
When your Active Directory DNS name not ends with "northland.ac.nz" and your pool/server DNS name note ends with "northland.ac.nz" you must enable StrictDNSNaming. Use Group Policy with Communicator 2007 ADM-File for your clients.

Communicator 2007 Policies Documentation and .ADM-File:
http://www.microsoft.com/downloads/details.aspx?FamilyID=dd3cae08-3153-4c6a-a314-daa79d616248&DisplayLang=en

Copied from administrative Template (ADM) for enable strict DNS naming description:

Disallow Microsoft Office Communicator to automatically detect and securely communicate with SIP servers that have non-standard fully-qualified domain names (FQDNs).

Note: This policy setting takes effect only if Microsoft Office Communicator uses "automatic configuration" to query DNS for a list of SIP servers, and only if Microsoft Office Communicator communicates with the SIP server using the TLS transport. In this case, the set of supported server FQDNs depends on the SIP URI of the user who starts Microsoft Office Communicator.

For example, if you disable or do not configure this policy setting, and the users SIP URI is SIP:USER1@EXAMPLE.COM, Microsoft Office Communicator can communicate with a SIP server in TLS transport only if its FQDN is either EXAMPLE.COM or SIP.EXAMPLE.COM. In other words, the FQDN of the server must exactly match the domain portion of the users SIP URI, or else the FQDN must be "SIP." followed by the domain portion of the users SIP URI. This prevents a "man-in-the-middle" security vulnerability: an attacker can detect the UDP message that the client uses to perform the DNS lookup, and respond to the client with the name of an unauthorized SIP server. The attacker could then impersonate a trusted user, or the server could cause the client to authenticate using weak encryption.

However, if you enable this policy setting, Microsoft Office Communicator can communicate in TLS transport with any SIP server that has an FQDN that ends with the domain portion of the users SIP URI. Continuing the previous example, by enabling this policy setting you allow Microsoft Office Communicator to communicate with servers named SIP.DIVISION.EXAMPLE.COM or LC.EXAMPLE.COM. However, an attacker can respond to the initial DNS query with a response that contains the server name ATTACKER.EXAMPLE.COM.

Note: You can configure this policy setting under both Computer Configuration and User Configuration, but the policy setting under Computer Configuration takes precedence.


Joerg Bachmann

----------------------------------------------------------------------------------------------------------
German Unified Communications Community Website - http://www.uc-community.de

0
 

Author Comment

by:northtecicts
ID: 22919021
Gaanothony:

yes:  is your communicator sign-in address like username@northland.ac.nz?

both do work:  You say manually specifying the server information Communicator works but autoconfiguration does not work?

I have added this back now (may have accidentally removed this too when removing _sip._tls from internal -sorry about that):  in your internal DNS you need the following SRV record for client autoconfiguration - _sipinternaltls._tcp.northland.ac.nz that points to .northland.ac.nz on port 5061

I ran the BPA and the only problem was the above missing _sipinternaltls._tcp

After adding this entry back and running the validation wizard on our front end server OCS console, we get no errors..


Dresdner:
I'm not sure about whether we have that group policy enabled or not, but when we implemented our OCS around year and a half ago, we decided that users' sip addresses could not be anything other than <username>@northland.ac.nz
Therefore, anybody trying to login with our alias will not be able to login - and this was our accepted initial design limitation.
Has this changed now, or would we need this enable strict DNS naming policy regardless?
0
 
LVL 1

Expert Comment

by:Dresdner
ID: 22919623
When your pool name is <poolname>.northland.ac.nz, you don't need this group policy.
0
 

Author Comment

by:northtecicts
ID: 22925591
Thanks, yes we do also use <poolname>.northland.ac.nz

After adding _sipinternaltls._tcp back again yesterday, we are still getting errors today on clients when they run / sign into communcator:

***
Communicator was unable to resolve the DNS hostname of the login server <poolname>@northland.ac.nz.
 
 Resolution:
 If you are using manual configuration for Communicator, please check that the server name is typed correctly and in full.  If you are using automatic configuration, the network administrator will need to double-check the DNS A record configuration for <poolname>@northland.ac.nz because it could not be resolved.
***

We definitely still have <poolname> Host A record pointing to our front end in our root northland.ac.nz forward lookup zone..

Could this have anything to do with the fact that the error is <poolname>@  instead of <poolname>.  ?

All clients appear to be functioning fine so maybe this error is just a false positive...
0
 

Author Comment

by:northtecicts
ID: 23039057
Hi.
Should these records be in external DNS?
_sipfederationtls._tcp.DomainA.com record in external DNS referencing host sip.DomainA.com on port 5061

_sip._tls.DomainA.com record in external DNS is referencing host sip.DomainA.com on port 5061

I have checked with our external DNS provider and these are setup exactly like this alrealdy so why would removing the sipinternal.DomainA.com internal recrods break things?
0
 
LVL 12

Accepted Solution

by:
gaanthony earned 500 total points
ID: 23042932
You records in external DNS are correct as I did an nslookup to verify.  Yes you need _sip._tls.domainA.com record for remote Communicator users and Live Meeting clients.
You only need _sipfederationtls._tcp.domainA.com if you are federating with other companies running OCS and you plan to use autodiscovery for federation instead of manually configuring the Access Edge information of yourself and the federation partner on both end.
When you say you removed sipinternal.DomainA.com and it breaks things did you run an IPCONFIG /Flushdns on the workstation or reboot the workstation before testing?
The only records you need in internal DNS is _sipinternal._tls.DomainA.com with pool.domainA.com host record in the DomainA.com forward zone in internal DNS which you say you have.
0

Featured Post

Transaction Monitoring Vs. Real User Monitoring

Synthetic Transaction Monitoring Vs. Real User Monitoring: When To Use Each Approach? In this article, we will discuss two major monitoring approaches: Synthetic Transaction and Real User Monitoring.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

My previous article  (http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2008/A_4466-A-beginners-guide-to-installing-SCCM2007-on-Windows-2008-R2-Server.html)detailed one possible method to get SCCM 2007 installed an…
On a regular basis I get questions about slow RDP performance, RDP connection problems, strange errors and even BSOD, remote computers freezing or restarting after initiation of a remote session. In a lot of this cases the quick solutions made b…
If you're a developer or IT admin, you’re probably tasked with managing multiple websites, servers, applications, and levels of security on a daily basis. While this can be extremely time consuming, it can also be frustrating when systems aren't wor…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question