Views:

  • The global FQDN “proxy.iws-hybrid.trendmicro.com” uses the AWS Geo Location policy, which is determined by the client's resolver IP rather than the client's IP.
  • Using the client's resolver IP to determine the location can sometimes be problematic since the client might use a DNS resolver which is located far away from the actual client's location.
  • Additionally, AWS Route 53 service supports the EDNS client subnet function; in this extension, DNS queries will carry the client's IP subnet information. If your end users' DNS resolvers support this extension, then the Route 53 service would be able to determine the client's location more accurately.
  • This is potentially one reason for which, when using Google DNS, the Route 53 geo-location policy can re-direct the customer to the correct location. You can refer to this Amazon Route 53 Forum Announcement for more details on EDNS-client-subnet

To confirm this behavior, we will need customers to run the following commands at the same time with a sleep time of 1 minute:

For Linux systems:

  • To get the current DNS' resolver IP

    dig +short resolver-identity.cloudfront.net 

  • To resolve our service FQDN proxy.iws-hybrid.trendmicro.com by the current DNS resolver

    dig +short +identify proxy.iws-hybrid.trendmicro.com

  • To check whether the current DNS resolver supports EDNS

    dig edns-client-sub.net TXT +short

For Windows systems:

  • nslookup resolver-identity.cloudfront.net
  • nslookup proxy.iws-hybrid.trendmicro.com
  • nslookup -type=txt edns-client-sub.net

For example:

In the following image, the client uses DNS 192.221.154.132. Since this IP address is in London, the proxy address is resolved to 52.56.127.241, which is the scanner instance in the London Data Center (DC).

However, in the following image, the client uses DNS 172.217.47.8. This IP is in India, so the proxy address is resolved to 13.126.23.129, which is the scanner instance in the India Data Center (DC).

This is why the customer sometimes goes to the London DC and sometimes to the India DC.

The IWSaaS team provides a Tool containing two scripts, to confirm the root cause:

  • For Windows systems: DNS_Resolver_Windows.bat
  • For Linux systems: DNS_Resolver_Linux.sh

Both scripts provide the same check functions:

  • Get the current DNS' resolver IP (Because the customer DNS' resolver IP may change).
  • Resolve our service's FQDN proxy.iws-hybrid.trendmicro.com by the current DNS resolver.
  • Check whether the current DNS resolver supports EDNS.

The scripts automatically get the above items 100 times and the interval is 1 minute, so it will last for about 100 minutes. If you do not want it to run for that long, you can stop it manually by pressing Ctrl + C.

Run the scripts when you find that the client connects to a region which is not expected; after running the scripts, you can collect the output files and send them over to Trend Micro for analysis.

 
The output file is in the current running directory: for Windows systems the file name is windows_output.txt, and for Linux systems the file name is linux_output.txt

  1. Use the IWSaaS regional FQDN.

    For example, if the customer is in India, they can use the FQDN “proxyst-as1.iws-hybrid.trendmicro.com”

  2. Use the DNS server which is in the same country as the user.
  3. Let the DNS Server support EDNS.

  4. Use the known recursive DNS providers who include ECS information in the DNS queries:

    • Google Public DNS
    • OpenDNS
Keywords: connecting to the wrong data center