4 March 2017

Filtering name resolution using a hosts file

The IP suite includes a useful configuration file named hosts. It is one of the methods your computer uses in order to find out the IP addresses for the computers you want to contact, such as when sending email or browsing the web.

Historically, name resolution on the Internet was performed exclusively using hosts files. Every administrator had to download a copy of the file from the network information centre. The copy, however, became stale as soon as a host name was added to, or deleted from, the master file, so downloads had to be frequent, which caused congestion.

After the DNS was introduced, hosts files shrank to near zero size. They are now used mostly utilized for resolving the name ‘localhost’ to the IP address 127.0.0.1 regardless of DNS server availability, since the hosts file is checked prior to the DNS.

This order is important, as it allows us to make name-to-address mappings no matter what the DNS would say. In other words, if a matching entry is found in the hosts file, the DNS is not queried at all. This feature can be put to use also for dealing with domain names you do not want to contact; list those unwanted names in your hosts file, and point them to somewhere safe!

How would this be useful? When you open an HTML email message, especially one of the unsolicited variant, the message often makes your mail program request things from web servers. Similarly, when you browse to a web page, the web server may instruct your browser to download things from other servers. These third-party downloads can be annoying, they may invade your privacy, or they can be downright dangerous to your computer and to the information on it. Your email, web, antivirus and firewall programs may be able to avoid them, but it does not hurt to stack the odds, especially if you have been burned by malicious downloads in the past.

Assume it is your opinion that foo.example.com should be avoided and that you therefore have added it to your hosts file (I will tell you how in a moment). When your web browser tries to download something from foo.example.com, the protocol stack tries to resolve foo.example.com, finds your safe-haven IP address in the hosts file and attempts a connection to that address. A moment later, the lower-lever layers will inform your browser that the HTTP request has failed. Your page will then load without whatever foo.example.com would have had in store for it.

There are ready-made hosts files available for download on the web. Some are several hundreds of kilobytes in size. You can use such a file as a starting point, or you can start from scratch, building your own file as you go.

Either way, in order to get started, you need to locate the hosts file on your system. Do a search for it. On Windows systems, the hosts file is usually located at %SystemRoot%\system32\drivers\etc\hosts, where %SystemRoot% stands for the Windows directory (often C:\Windows). You must use an account with sufficient permissions; on a Windows system, you would typically need to be a member of the Administrators group.

Now open the file in your favourite text editor. On a Windows system, you must launch the editor using the ‘Run as administrator’ option; just being logged in with administrative rights is not enough. Make the additions you want. For example, assuming you would like to add foo.example.com, create a new line and type, for instance, 127.0.0.2 foo.example.com on the empty line.

When you are done, your file might look something like this:

# Lines beginning with the pound sign are comments.
# They are not parsed.
#
127.0.0.1 localhost
# The above line is important. If you erase the contents of the file in
# order to start anew, be sure to begin with an entry that points localhost
# to 127.0.0.1.
127.0.0.2 foo.example.com # Comments can also begin in mid-line.
127.0.0.2 bar.example.com

Now for the restrictions: wildcards, such as *.example.com, will not work. In addition, if the access attempts are made directly to an IP address, with no name resolution involved, the hosts file is obviously powerless. Still, a good hosts file can stop a lot of undesirable traffic.

About the choice of IP address: you can any address from 127.0.0.1 up to 127.0.0.255, at which point you could continue at 127.0.1.0, and so on all the way to 127.255.255.254! The entire 127.0.0.0/8 network (127.0.0.0–127.255.255.255) is reserved for loopback, in other words for ‘this’ computer.

Note that if you run a personal web server on your workstation, you could potentially run into surprising results such as error messages or authentication prompts. I therefore suggest careful planning if you intend to use both a personal web server and the hosts filtering described here. Maybe you could use a non-loopback address, in which case you would need to consider at least the timeout issue; or maybe you could tune your web server configuration to handle these HTTP requests in some special manner.

A hosts file is not an adequate replacement for antivirus and firewall software or for responsible usage. However, there are some good reasons for using a tuned hosts file in addition to antivirus and firewall software:

  • Adding a domain name to a text file is often easier than going through the graphical user interface of the firewall.
  • The hosts file is easy to copy across workstations, such as for backup or distribution purposes.
  • Hosts files are easy to share and download on the net.
  • Even if your firewall receives automatic access list updates, there is no guarantee that a particular host which you wish to avoid ever makes it onto those updates.
  • The access list of your firewall might accept only IP addresses, not domain names.