Solved

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

Posted on 2008-10-28
13
5,602 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
  • 5
  • 4
  • 2
13 Comments
 
LVL 12

Expert Comment

by:gaanthony
Comment Utility
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
Comment Utility
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
Comment Utility
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
 

Author Comment

by:northtecicts
Comment Utility
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
Comment Utility
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
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 1

Expert Comment

by:Dresdner
Comment Utility
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
Comment Utility
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
Comment Utility
When your pool name is <poolname>.northland.ac.nz, you don't need this group policy.
0
 

Author Comment

by:northtecicts
Comment Utility
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
Comment Utility
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
Comment Utility
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

Are end users causing IT problems again?

You’ve taken the time to design and update all your end user’s email signatures, only to find out they’re messing up the HTML, changing the font and ruining the imagery. What can you do to prevent this? Find out how you can save your signatures from end users today.

Join & Write a Comment

Welcome to my series of short tips on migrations. Whilst based on Microsoft migrations the same principles can be applied to any type of migration. My first tip Migration Tip #1 – Source Server Health can be found listed in my profile here: http:…
There have been a lot of times when we have seen the need to enter a large number of DNS entries in a forward lookup zone. The standard procedure would be to launch the DNS Manager console, create the Zone and start adding new hosts using the New…
It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring. It works on many operating systems, in many languages.
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

728 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

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now