This is the first part of a new series named Debugging common .NET exception. For this first installment, we'll take a look at System.Net.WebException with the message of "The remote name could not be resolved: 'name'". WebException is an umbrella-exception, used for a lot different errors when dealing with web requests in C#. The exception type contains detailed information about the actual error that is happening. Information that will help you debug what is going in. In this post, we'll focus on resolving the remote name.
So, what does "The remote name could not be resolved" mean? As you probably already know, requests over the Internet are made using a domain name system (DNS). When you request google.com, your client asks a DNS for the IP address of google.com. When returned, your client makes a request to the IP specified by the DNS. This process is called "Resolving". You can think of DNS as the phonebook of the Internet. When you HTTP request throws an exception, telling you that the remote name could not be resolved, it basically means that an IP address couldn't be solved from the provided domain name.
Handling the error
Figuring out why the DNS resolve fails can be everything from a piece of cake to extremely hard. Before we start digging into debugging, let's look at how web exceptions can be handled in C#:
using System.Net;
namespace WebExceptionDemo
{
public class Program
{
public static void Main(string[] args)
{
try
{
var request = HttpWebRequest.Create("http://some-domain-that-doesnt-exist.com");
var response = request.GetResponse();
}
catch (WebException e) when (e.Status == WebExceptionStatus.NameResolutionFailure)
{
// Do something with e, please.
}
}
}
}
In the example, a request to the non-existing domain some-domain-that-doesnt-exist.com is made. This will cause the WebException with a Status of NameResolutionFailure to be thrown.
Debugging the error
As promised, let's look at how to figure out why this error is happening. The cause is most often a problem with the Internet connection or an invalid hostname (like the example in the previous section). The easiest way to figure out if this is the case, is to use the Ping command in Windows.
Root cause analysis using Ping
Open a new command prompt by clicking the Windows button and typing cmd.
Ping the desired domain name by executing the following command:
ping some-domain-that-doesnt-exist.com
The result looks similar to this:
To find out if you are in fact connected to the Internet, ping Google's DNS server:
In this case, we can get a response back from the server. If your computer cannot connect, you will see a message similar to this:
When you verify a working Internet connection, ping a domain that you expect to be working (like google.com):
In the example, requesting google.com worked. If this is the case, resolving an IP from your domain name (some-domain-that-doesnt-exist.com), must be the issue. If pinging google.com resulted in the same error as when pinging your own domain, there is something wrong with the DNS.
Setting up DNS
In order for ping to be able to resolve an IP from the inputted domain name, you will need to set up an entry in a DNS. How you do this, varies from DNS to DNS. In this example, a mapping between the domain name elmah.io and the IP 52.42.13.100 is configured in Cloudflare:
Look for documentation on how to correctly set up a DNS record with your hosting provider.
Notice that it can take up to 24-48 hours for the new DNS record to propagate. To flush your DNS cache, read through the following section.
Common DNS issues
If you believe that the DNS has been set up correctly, failing in resolving the IP can be caused by a number of other issues.
To speed up domain name to IP resolving, results are cached in your machine. To flush the cache, execute the following command:
ipconfig /flushdns
This will flush the local DNS cache:
Also make sure to flush your browsing history in order to test the domain name from the browser. All browsers allow for easy clearing this data. In this example, Chrome:
Make sure to select "All time" or what sounds equivalent in your browser.
Nslookup
Another useful tool to help track down DNS problems, is Nslookup. Nslookup provides similar features to Ping, like resolving a hostname:
nslookup elmah.io
Nslookup also provides reverse lookup (IP to domain name):
nslookup 8.8.8.8
To inspect DNS records from a domain, use Interactive mode:
nslookup
server 8.8.8.8
set q=TXT
google.com
In this example, we query the DNS server 8.8.8.8 for TXT records on the domain google.com:
For a detailed trace of what's going on behind the scene and which DNS servers that are involved, use the -debug parameter:
nslookup -debug elmah.io
Regional DNS issues
You might experience a situation where some of your users experience a DNS resolve error and some don't. This can be caused by the fact that there are typically more than one DNS server involved in resolving the same IP address from multiple regions. Secondary DNS servers are spread across the world and all synchronize with the primary DNS where your domain is configured.
Regional DNS servers and even the local DNS cache can be out of sync, a secondary DNS in a single region can be down, and similar problems.
Free services like Ping Test, can ping your domain from multiple regions. Using an automated service like elmah.io Uptime Monitoring, is a better way to ensure your URLs are available from multiple zones and not only where your local machine is located. Similar services like Pingdom and StatusCake also provide this feature, but will require more configuration, since those services as a default only request your endpoint from a single region per iteration.
Also make sure to read the other posts in this series: Debugging common .NET exception.
Would your users appreciate fewer errors?
elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.
➡️ Error Monitoring for .NET Web Applications ⬅️
This article first appeared on the elmah.io blog at https://blog.elmah.io/debugging-system-net-webexception-the-remote-name-could-not-be-resolved/
Top comments (0)