northtecicts
asked on
reappearing event logs - cannot resolve DNS sip.domain.com, sipinternal.domain.com
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
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
ASKER
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.Domai
we also have _sipfederationtls._tcp.Dom
_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
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.Domai
we also have _sipfederationtls._tcp.Dom
_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
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.<sipd
_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.compa
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.<do
==========================
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.Domai
Remove as this is an external DNS record for federation. we also have _sipfederationtls._tcp.Dom
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.
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.<sipd
_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.compa
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.<do
==========================
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.Domai
Remove as this is an external DNS record for federation. we also have _sipfederationtls._tcp.Dom
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.
ASKER
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.north
***
Any other suggestions of what else we could change?
Do you think it may be some problem other than OCS configuration?
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.north
***
Any other suggestions of what else we could change?
Do you think it may be some problem other than OCS configuration?
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.north
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/d
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.
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.north
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/d
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.
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
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
ASKER
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.north
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?
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.north
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?
When your pool name is <poolname>.northland.ac.nz
ASKER
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
***
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...
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
***
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...
ASKER
Hi.
Should these records be in external DNS?
_sipfederationtls._tcp.Dom
_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?
Should these records be in external DNS?
_sipfederationtls._tcp.Dom
_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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.mydom
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/rf
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