Debugging: System.Net.WebException - The remote name could not be resolved

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:

ping domain that doesn't exist

To find out if you are in fact connected to the Internet, ping Google's DNS server:

ping google's dns

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:

missing internet connection

When you verify a working Internet connection, ping a domain that you expect to be working (like google.com):

pinging google

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:

dns record 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:

flush dns

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:

clear chrome history

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 elmah.io

Nslookup also provides reverse lookup (IP to domain name):

nslookup 8.8.8.8

nslookup reverse lookup

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:

query txt records

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.



This post was brought to you by the elmah.io team. elmah.io is the best error management system for .NET web applications. We monitor your website, alert you when errors start happening and help you fix errors fast.

See how we can help you monitor your website for crashes Monitor your website