Domain blocked in Windows hosts file, but the site is still accessible

Question

I'm trying to figure out why my hosts file isn't being honored correctly. And by correctly I mean, when I visit the website I'm trying to block it takes about 12 hours for it to take effect.

And yes, I know this question is similar to [this one] (https://serverfault.com/questions/50934/hosts-file-being-ignored) and no nothing proposed there solved the problem.

Background: I'm trying to block youtube from my son's computer during school hours. My router allows for blocking and on a schedule but it affects my whole network. Now, I know, I can just get a good, configurable firewall appliance (e.g. Firewalla, pfSense, Untangle, etc.) or add a second wireless access point, have his laptop connect to that, and create a block rule on that second AP. But, I'm an idiot, and I choose the hard route.

So what I was thinking was to create two alternate hosts file, one with this line to block YouTube:

127.0.0.1 youtube.com

and another without. I then created two batch scripts to replace the hosts file according to a schedule using the Windows scheduler. Here's the batch script:

ECHO OFF
SET COPYCMD=/Y
xcopy /V /Y C:\Windows\System32\drivers\etc\hosts_YT_OFF.txt C:\Windows\System32\drivers\etc\hosts
IPCONFIG /flushdns

So, when I execute the script (haven't even got to the scheduler step yet) it works as it's supposed to, sorta (and by "sorta" I mean that yes, technically, it has worked but it took over 12 hours to take affect).

Check the hosts file: yes, it's been replaced correctly.

Ping "youtube.com":

C:\WINDOWS\system32>ping youtube.com

Pinging youtube.com [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

As you can see, the hosts file is being honored. Check the dns cache:

C:\WINDOWS\system32>ipconfig /displaydns

Windows IP Configuration

youtube.com
    ----------------------------------------
    No records of type AAAA


    youtube.com
    ----------------------------------------
    Record Name . . . . . : youtube.com
    Record Type . . . . . : 1
    Time To Live  . . . . : 0
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 127.0.0.1

Tried this:

C:\WINDOWS\system32>nbtstat -R

No change.

Did this:

C:\WINDOWS\system32>ipconfig /release
C:\WINDOWS\system32>ipconfig /renew

Again, no change. I mean, it does disable the adapter and renew it, but I can still access YouTube on Chrome, Firefox, Edge. And yes, I've restarted the browser, and cleared the caches. Nothing.

I have not restarted the computer though, and I don't intend to. For one, it will eventually disable YouTube. And two, when I ping youtube.com it comes back localhost, so, why should I? Something is mucking this up and I'm too damned stubborn to let it go and take the aforementioned, easy solutions. :P

The hosts file is being replaced correctly, as is with the second script which just replaces the blocked youtube hosts file with the default one when I want to re-enable youtube access. And I've confirmed that with pinging and being able to access YouTube after it was successfully disabled (which only happened like 12 hours later).

I hope all of this makes sense. There has to be some very simple Windows network explanation for this that I'm missing. Any help would be greatly appreciated.

Update 9/11/2020. I got it to work. The problem was I needed to add this additional address to the hosts file:

127.0.0.1 www.youtube.com

That's it. Nothing complicated at all, just a "www". I'm not sure why, as I thought the domain name would cover it. Nope. Sigh. So now it reads:

127.0.0.1 youtube.com
127.0.0.1 www.youtube.com

Answer 1

Since MS Windows ignores some specific hosts rules, and even considers some such attempts a security risk, you might try making a Firewall Rule to block specific sites. One rule can block multiple URL's. You can make a batch script to activate the rule:

netsh advfirewall firewall set rule name="TestRule" new enable=yes

Or use ... enable=no to inactivate it.

• Press Windows, type firew, and select Windows Defender Firewall with Advanced Security.
• Select Inbound Rules.
• Select New Rule... under Actions.
• Select Custom rule.
• Under Scope, Add the many Remote IP address for YouTube.com, e.g., 172.217.6.238 (see below)
• Under Action, Block the connection.
• Repeat, if needed, for Outbound Rules.

N.B. Blocking a single IP address is useless, because YouTube owns many IP addresses, e.g.,

• Individual addresses:
  • 208.65.153.238
  • 208.65.153.251
  • ad nauseam
• Ranges of IP addresses:
  • 199.223.232.0 - 199.223.239.255
  • 207.223.160.0 - 207.223.175.255
  • and many others that haven't been discovered, as T. Lehrer put it.

Caveat: These Firewall rules can be bypassed, and also will need to be updated as YouTube adds more IP addresses.

Answer 2

Some programs maintain their own cache of DNS lookups.

Therefore, for such programs, you'll also need to tell the program to clear its cache, if it offers a way to do this.

Answer 3

The problem here is that the hosts file (as the name implies) contains host name entries, not domain name entries.

youtube.com happens to be a host name, which is the reason why you can navigate to it with a browser, and why that entry in the hosts file effects something at all.

As you already have figured out, www.youtube.com is another host name where the same contents can be reached. Thinking this further, you will run into problems with this method, because you can't know how many other host names YouTube uses.

For example, m. instead of www. is still often used (especially by big sites) for the mobile version of a site. Therefore, I just tried m.youtube.com, and it worked. I haven't investigated thoroughly, but this seemed to just cause a redirect. However, depending on how old (i.e. how smart) your son is, it will be sufficient to find out the needed IP address (e.g. open cmd and issue ping m.youtube.com). I assume that there is a bunch of other host names which lead to the YouTube contents.

To summarize, it is not domains, but host names which you enter in your browser's navigation bar and which you put into the hosts file, and unfortunately, in the first place, you don't know how many and which host names resolve to the same host, which is one of the reasons why protection systems like that you described cannot be bullet-proof.

[There are methods to investigate what host names are used in a domain, but I believe that those details would be off-topic here, and there are other caveats with your protection system. Plus, YouTube could add and remove additional host names at any time, so you would have to check that regularly.]