From time to time, we saw attempts on proxy or firewall trying to go out for the following destinations:
sip.example.com
sipinternal.example.com
sipexternal.example.com
Because the domain example.com is reserved in RFC 2606, those hosts don’t actually exist, so all the attempts failed. Consider the number of users in the network, how many resource had been wasted due to this kind of nonsense traffic? If there is a proxy configured, the client will periodically send requests to the proxy, the proxy then need to authenticate and process the request. If user has direct connection, the DNS need to resolve this non-existing hostname every few minutes. Think if there are 1000 users in the same situation in your network.
Here is the log that shown on the proxy server from one client, the attempts repeat every few minutes:
The question then became where the traffic are from and how to stop them.
SIP is the keyword, it must be from an instant messaging client. So on the client machine, we found only Office Communicator was installed but not configured ever since. The Sign-in address (URI) was the default someone@example.com, and somehow it starts observing or connecting to all three hosts mentioned in the begining of this article.
I searched the Internet for similar complaints, most of those have three hostnames are Microsoft official documents – OCS Deployment Guides and Communicator Testing Guide. The domain example.com are real examples in those documents.
There is only one thread in Microsoft online community discussed about the issue. worb68_ocs brought up the same concern that I have. The only answer that closes to the root cause was from Turgay Ongun in Microsoft:
When you install the Communicator client and run it as the very first time, the textbox where you enter your SIP address is someone@example.com
If by mistake, any user click the sign in button without entering his/her SIP address, then the communicator tries to find the edge server for example.com for someone@example.com SIP address.
All other answers were not quite straight forward.
So the next step is either remove Office Communicator if user is not using it, or configure it by a correct sign-in address, or disable automatic login if it’s not in use all the time.
Microsoft should also do something in their next release of Office Communicator or Lync client, they should leave the Sign-in address blank or lead user by a wizard to put in some more meaningful address/URI instead of just dropping a example like someone@example.com.
Here is the thread address:
http://social.technet.microsoft.com/Forums/en-US/ocsmanagement/thread/394de0c5-8f6d-4acf-886d-14d67eebe510
Some extend readings:
http://technet.microsoft.com/en-us/library/dd637152(office.13).aspx
http://technet.microsoft.com/en-us/library/bb457114.aspx