Host file not redirecting

Question

I've been playing around with my Windows 10 host file to get a better understanding of how it works and I've not been successful in redirecting an address yet.

I'm trying to redirect yahoo.com or www.yahoo.com to 216.58.209.36 (www.google.com), im putting:

216.58.209.36  yahoo.com
216.58.209.36  www.yahoo.com

But when I try loading it in my browser it tells me

This site can’t be reached

www.yahoo.com took too long to respond.

Does anyone know what I'm doing wrong?
I've also tried clearing my browsing history.

Solution

I believe you are misunderstanding the purpose of the hosts.txt file.

If all you care about is the TL;DR (too long; didn't read), then scroll down to the bottom of the answer. What follows is an explanation of what's going on, to help you understand why you are getting the results you are getting.

hosts.txt (typically /etc/hosts on Unix-like systems) provides a mapping between a host name and an IP address. The system name resolver is then typically configured to prefer hosts.txt entries over DNS, such that hosts.txt can be used as a DNS override. This is useful particularly in cases where local names don't exist in DNS, but you simply don't have enough hosts on your network to warrant setting up a local all-out authoritative DNS server with all of what that entails.

However, modern web browsing relies on far more than just the name to IP address mapping.

The typical process goes like something similar to:

1. User enters a URL into the browser's address field, or otherwise triggers a web request
2. Browser looks up the host name from the URL, to an IP address, and connects to that IP address
3. Browser sets up a HTTPS session, if the url is a https:// URL

• Browser aborts if the certificate presented does not match the host name in the URL

4. Browser tells the remote web server to give it path /something/whatever from the host name from the URL
5. Remote web server responds with the requested resource, or typically an error if the request cannot be fulfilled for some reason
6. Browser interprets and displays or acts on the data received from the remote web server

• If the data received is a redirection, then the process starts over on step 1 with that URL instead

By editing hosts.txt you change only what happens in step 2 above. Web browsing is a lot more complex than just a name lookup!

Also note that web browsers sometimes implement their own name lookup functionality, instead of offloading to the resolver provided by the operating system. In such a case, even step 2 won't necessarily get you the result you are after, because it might very well follow the normal name delegation path from the DNS root, so you get the same response as you otherwise would; in that case, hosts.txt never gets consulted!

Notably, the browser will still be expecting a certificate for the specific host name in the URL in step 3; and it will tell the remote web server the host name you gave it in step 4.

Since Google's web servers are unlikely to be set up to serve www.yahoo.com, whether over HTTP or HTTPS, this fails no later than between step 4 and 5 (the remote web server cannot provide the requested resource).

I have no good explanation for why you are getting a timeout rather than a web server error response, but the means of failure is largely up to the remote server, so I suspect it is well within its rights to not respond at all when asked about a host it simply doesn't know about.

And of course, if you are just experimenting, there is no need to use Yahoo or Google. Rather, there are Internet IP addresses and host names specifically set aside for example and documentation purposes which are good for this. For example, you could use 192.0.2.100 for the IP address and test.example.com for the host name, as neither of these belongs to anyone in particular. That, or RFC 1918 space (10.0.0.0 through 10.255.255.255, 172.16.0.0 through 172.31.255.255 or 192.168.0.0 through 192.168.255.255), but you'd still want a corresponding domain name, for which those reserved are good.

TL;DR:

If you want to see that your hosts.txt entry is doing what it should, then open a command prompt and issue the command ping -n 1 www.yahoo.com (in your case). It should respond with the IP address you configured. The -n 1 causes only a single echo request to be sent, because all we are really interested in is the results of the name lookup.

I would prefer nslookup www.yahoo.com, but apparently on Windows nslookup doesn't look at hosts.txt either. (On Linux, it typically does, because it asks the system resolver and the system resolver is normally configured to consult the hosts file; if you want a pure DNS lookup on Linux, you'd typically use host or dig instead.)

Comments

[user]

Not all sites on the Internet respond to ICMP echo requests. Many of the big ones probably do. In this case, there's no reason to use ping in the first place; nslookup is probably more relevant, since all you are interested in is the IP address mapping for the name.

[FastEthernet]

@MichaelKjörling ping will still show the IP address of the target, whether it responds or not. Also, nslookup does not look in the hosts file as it asks the name server directly.

[I say Reinstate Monica]

@MichaelKjörling It's not necessary for the site to respond to the ping requests for this test to work. And IIRC nslookup by bypasses the hosts file.

[user]

@FastEthernet Of course it's not necessary for the remote host to respond to ICMP echo requests in order to perform a name lookup, but why clog the pipes unnecessarily?