How To Debug The Error " No Such Host Is Known" ?

News Knowledge Base
,
1

How to debug the error " No such host is known "?

Issue Description: How to debug the error " No such host is known" ?

Root Cause: This error can happen anytime an application is trying to resolve a URL. In the most common scenarios it will be thrown by the Robot when executing an automation and specifically when it is making URL requests.

DNS In Windows:

For a more detail explanation of the following points see the section DNS In Windows Technical Details.

For the purpose of debugging just remember these key points:

  1. UiPath does not control the DNS timeout of the Robot, rather the timeout value is inherited from the windows system settings. (This may not be true of all our applications but should apply for any .Dotnet applications).
  2. DNS should typically not take more than a few 100ms to resolve. See: https://www.dnsperf.com/
  3. Most DNS issues are probably caused by internal network issues. For cloud services its possible there is an outage but less likely.

Diagnosing / Resolving

  1. These steps assume that it has already been established that there is a DNS issue. The typical error one might see is something like this:
    • (No such host is known. (cloud.uipath.com:443))
  2. First enable the DNS logs on the windows machine.
    1. See the following article for how to launch the event viewer: How To Get Application Logs From The Event Viewer
    2. Once the Event Viewer is open, navigate to the DNS client logs.
      • Applications and Services Logs -> Microsoft -> Windows -> DNS Client Events
      • Expand the DNS Client Events and right click 'Operational'
      • Select 'Enable Log'
  3. Next try to trigger the issue.
    1. Open a command prompt or powershell.
    2. Run: ipconfig /flushdns - This flushes the DNS which will hopefully help trigger the issue.
    3. Make a call to the endpoint. This can be done with curl.
      • curl <endpoint>
      • i.e. curl https://cloud.uipath.com
    4. If the curl command times out, the issue was reproduced.
  4. Alternatively wait for the error to occur. In such a case the following needs to be done:
    1. From the Robot logs, make a note of when the issue occurred.
    2. Logon to the Robot machine and gather the logs from a 5 minute interval from before the issue happened to a five minute interval after.
    3. After the logs are captured, make sure to make a note of the endpoint that could not be resolved.
    4. The logs can be sent to your network team or shared with UiPath.
  5. Gather debug logs of nslookup
    1. Open a command prompt and run: nslookup
    2. Next run: set debug
    3. Then make the DNS query by typing in the hostname that is not resolvable.
      • i.e. run: cloud.uipath.com
    4. Capture the output.
    5. To exit nslookup type: exit
  6. Another test that can be done is to use nslookup to make the query to a different DNS server. For example, lets say that the Robot sometimes cannot resolve cloud.uipath.com and by default it contacts internal servers. To determine if its a general network issue or a problem with internal server we might try the following test
    1. Run nslookup as in the above instructions.
    2. However, when query the cloud.uipath.com, use a public DNS server (8.8.8.8, google dns, is always a good one)
      • In this case cloud.uipath.com is on public dns, so we can resolve it with a public dns server.
      • i.e. cloud.uipath.com 8.8.8.8
    3. If the above request timed out it could mean:
      • A general network issue that affects all DNS queries.
      • For the case of a public address, it could be that there is a service outage.
      • If this happened with UiPath, it is required to check if there was any outages.
  7. As a workaround the default timeout values can be changed:
    1. The Microsoft defaults should be more than adequate.
    2. The registry location for these changes are:
      • HKLM\System\CurrentControlSet\Services\dnscache\Parameters\DNSQueryTimeout
      • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DNSQueryTimeout
    3. Under Parameters a Multi-String Value must be created with the name DNSQueryTimeout
    4. For the values to enter see: DNSQueryTimeouts
      • Also from testing and the previous link, it seems that the defaults have changed from what is in the link.
      • One might change the values to 2, 4, 4, 8, 10, 0
      • The last entry always has to be a zero.
    5. When entering the values, they must be seperated by line. Here is an example of how the values would be entered:
image.png
  1. If the issue is easy to reproduce, a wireshark trace can also be helpful in identifying the issue:
    1. How To Get A Wireshark Trace?
    2. However, it Is probably better to engage network team if the issue is easy to reproduce
  2. Finally, gather the logs and share them with the network team
    1. In most cases like these, the issue is caused by internal infrastructure that is outside of the UiPath applications control.
    2. However, share the info with UiPath. When opening a ticket include the following:
      • nslookup output
      • DNS event viewer logs
        • Make sure to include the timeframe of when the issue occurred and the endpoint that was not resolvable.
      • Robot logs showing the error
      • Wireshark if it was generated.
    3. From the above information, UiPath would determine if it was an issue with our services (in the case of cloud) or an internal network issue.


DNS In Windows Technical Details

This is a short primer that can be helpful in debugging this error. For the most part when Automations are executing activities, the library used to make the HTTP requests will be a dot net library (In most cases System.Net.HTTP).

This library takes care of all the internal TCP/IP connections required for an HTTP request. Under the covers it is using system.net.sockets which intern uses system.net.dns. At some point this library will make a system call to the Windows OS DNS resolver to resolve the DNS name used for the HTTP request.

When the system call is made, UiPath does not control the timeout value for the DNS query. The only control it has is on the timeout for the HTTP request itself. In the parameters for the HTTP request there is no DNS timeout option. Additionally, in the actual DNS library there does not seem to be a timeout parameter either ( See: Dns.GetHostAddresses Method ).

If .DotNet is imposing a limitation, it would be a timeout value on the call to the DNS library itself, but from testing there currently does not seem to be any limitation.

The timeout value is actually controlled by the Windows system itself and has to be changed by re-configuring system settings. However, the system defaults should be adequate. There are many publically available resources for understand DNS performance, but typically, the expectation is that a DNS request should resolve in a few 100ms. To see the performance statics of public DNS servers see: https://www.dnsperf.com/

Regarding the default timeouts for windows see: DNS Client Resolution Timeouts.
Note: From Windows link, one might misunderstand the document to be saying that on Windows a DNS query has 10 seconds to resolve. This is not true. A request to the DNS resolver has 10 seconds to resolve but the resolve makes a series of request that timeout after 1 second, then 1 second again, then 2 seconds, then 4 seconds and then 2 seconds again. This means that at most a query must resolve in at least four seconds.

Finally when a client makes a DNS query, if the DNS server does not know the answer, it makes a query to another DNS server (so its not the client make a DNS query to another server to find the answer. This is important to realize because it could be the DNS server has slowness querying upstream servers and not a client issue).