It's time to rethink the HOSTS file

With attacks on DNS servers increasing and the creation of "typomains" such as "googkle", it may be time to rethink that old relic, the HOSTS file. It can be used to ensure a connection failure to domains you wish to avoid.

In the early days of the ARPAnet, there was a single downloadable HOSTS file at the Stanford Research Institute, mapping all the IP addresses of all connected machines to user-friendly names. This worked well when 100 hosts were involved; later, it got sticky— and DNS was created. The idea of using a local HOSTS file became less popular, although the capability to do so remained.

With attacks on DNS servers increasing and the creation of "typomains" such as "googkle", it may be time to rethink that old relic, the HOSTS file. It can be used to ensure a connection failure to domains you wish to avoid. Map undesirable domains to the loopback IP address, The resolver service's job is to provide an IP address when queried with a name, and if it can do that it doesn't care how wrong it is. Make that fact work for you and not against you.... and for sure don't let it work for somebody else.

The name resolution order for Win2k and WinXP is

  1. Check that the name is not the local host itself; if not, then
  2. Check the HOSTS file; if not found, then
  3. Query the designated DNS server, then
  4. Send a query through NetBIOS

A few notes on that lookup order

  • WinNT4 up until SP4 (and beyond) tended to go through one of the NetBIOS-based name lookup routes. DNS was usually late in that lookup order, depending upon node configuration. With W2k that changed to reflect the Microsoft trend of phasing out WINS and NetBIOS usage.
  • The "real" second step is to check the machine's local DNS cache in memory. The HOSTS file is loaded into memory on boot— the machine does not read the actual file during a lookup. Edits to the HOSTS file may or may not take instant effect, so run IPCONFIG /flushdns after any changes to the HOSTS file are made.
  • Change the lookup order (or even remove a name-resolution resource) in the Registry or by editing .INI files, depending upon the OS.

Important— when editing the HOSTS file:

  • Double-clicking the HOSTS file results in a question box. Select NotePad, or any other plain text editor.
  • The very first entry should be localhost. Nobody knows why. Just do it. Things might break if you don't.
  • Any text after a "#" character on an entry line is ignored until the next hard return; insert comments this way (similar to "REM").
  • Never include an "http:" in a domain name and always omit the trailing slash. Examples:, not, and not

(This is easy to forget when Copy/Pasting from the Address box.)

  • Don't map an IP address to an IP address. Example:, not
  • Keep entries below 255 characters.
  • Most importantly, the filename must be saved as plain "HOSTS", with no extension appended. If necessary remove the extension by renaming it.
  • Each OS looks for the HOSTS file in specific paths:
WinNT/2000 — C:\winnt\system32\drivers\etc
WinXP/2003 — C:\windows\system32\drivers\etc
W95/98/ME — C:\windows
UNIX/Linux — /etc
Mac OSX — /etc

Defending your HOSTS file

Control of the HOSTS file means total control over Internet usage at a primal level down deep in a computer's hypothalamus, and that's a very attractive prospect to certain personalities. View the file size occasionally in Windows Explorer. If you left it at 67KB after your last edit and it's now 3KB, that's a clue.

Have a backup copy right in the same directory. It can be named "HOSTS.txt" with no conflict. Rename a corrupted file to "HOSTILES.txt" or such (you may wish to study it later) and do a "Save As" on the backup copy, removing the ".txt" extension— then flush the DNS cache.

Make the HOSTS file "Read-Only" through Properties or by using ATTRIB at the commandline. This works even better if done with the Administrator account and you surf the Web only via a Power User account with nothing but Read rights to the HOSTS file.On the Domain level, another layer of protection is available:  As Domain Admin, Take Ownership of the HOSTS file, change its attributes to "Read-Only", remove Local Admin rights, and turn off Inheriting From Parent....the file cannot now be edited, moved, or renamed even by an account with Local Admin rights.

Many anti-spyware utilities such as Microsoft Windows AntiSpyware and CounterSpy, and some personal firewalls such as ZoneAlarm, allow the option to guard the HOSTS file and/or generate a prompt upon any attempt to tamper with it.

Prefab HOSTS files

Several are available; search under "hosts file" and you'll find them. This— —is a good merged, purged, and alphabetized composite of several. In the pre-Pentium days, a large HOSTS file was overhead; with a modern CPU in the multi-GHz range and several hundred MB of RAM, it's not an issue. Look through these and see how many are the sources of spyware that you've expended hours in removing. Even the dreaded keylogger Trojans lose much of their threat if they can't even phone home(!)

If a security bulletin mentions any domain as a source of evil, add that domain to the HOSTS file so no users can go there by honest mistake. Also, consider adding good entries for your favourite sites. This will avoid a DNS lookup (if it's not in cache), speed up your surfing even when the servers are up and running, and ensure access to sites if your DNS servers are down or corrupted.

One small but vital caveat:  If anything Webwise suddenly quits working, examine the HOSTS file for possible problems *first*. You may have to delete an entry for some sites to function properly, especially certain Webmail apps.

Field testing

A prefab HOSTS file was downloaded (with a few entries added by hand) and loaded onto a couple of users' machines. Two or three weeks of "normal" Internet research (and surfing) went by, and the machines were then checked for spyware. Usually, in that interval, these particular machines have been known to pick up three to five hundred spyware items— with the tailored HOSTS file added, they each showed up with only.... ONE.

As a result of these trials, this HOSTS file is now verified via script, upon login, for every user in this 200+ machine network, reloaded if corrupted, and updated centrally as needed. Even if a user's HOSTS file somehow gets commandeered, it won't be for more than a day.... new entries will be added as new threats emerge, and effectively blocked with every new login. For a 0-day solution, all users will be requested to reboot; problem solved.

So rethink the HOSTS file. It can be an easily managed and effective tool for both SysAdmins and home users, and it costs nothing. Use it as one more layer of defense against several types of hazards in an increasingly hazardous Internet environment.

Editor's Picks

Free Newsletters, In your Inbox