In my current linux computer, i have 2 lines like these in my /etc/hosts file:

I put these lines there to avoid *all* content from that domain being downloaded in this computer. But i recently noted that a webpage which body contains the lines

really *has* content showed in Firefox! I and trying to directly open the address http://page2.gsa.com/page/show_content.js in my computer shows content.

What am i doing wrong? I tested this when i made a big set of those changes.

There is no proxy in use - if that would make any difference.

My guess: Your computer gives DNS priority over /etc/hosts. This behaviour can be changed in /etc/nsswitch.conf, if your computer uses it.

1 members found this post helpful.

My /etc/nsswitch.conf is:

Does that line mean it should look in /etc/hosts before doing DNS in a server?

The page

https://www.dummies.com/programming/...tch-conf-file/

says:

The OS is Debian, but searching with its name in query brought the same results.

You don’t have any type of dns caching enabled do you? And I’m assuming you tried clearing Firefox cache as well as rebooting? Just trying to cover al the bases here.

/etc/hosts works for HOSTnames only, not for full domains, so gs2.gsa.com is NOT covered by your hosts file. And I would put them in a single line

3 members found this post helpful.

This is good to know!

So it’s just a “block them as you see them” approach you have to do? Is there a way to find all of their domains with a dig command or anything like that?

It is important to cover such things. I would not know how to.

The computer rebooted with both files as they are now. I made no modifications to them since the last boot.

But something weird happened. Follow these details to know my context to use Firefox:

1. I have 4 config profiles for it. Two of these profiles are used practically all the time. Their need is due different settings i use for some sets of websites - and my wish to given them the least possible liberties. The 2 other profiles are for eventual uses, and one of them is used/created/recreated in a folder inside /dev/shm (RAM), so it can be quickly destroyed or anything i eventually want to experiment with it.

2. The profile NOJS has javascript disabled (among other details).

3. The profile JS has javascript enabled (among other details).

4. The profile INRAM is frequently (re)created with all default settings, since i usually do not copy anything to the folder it is configured to be (like copying the NOJS or the JS profile folders contents to it).

With that context, NOJS and JS profiles being used for days, with normal and private windows opened for *both*, i did these steps:

1. I used the INRAM profile, opened the page with those unwanted parts, and they were not there. So your guess found the problem?

2. I deleted *all* files, hidden and normal ones, inside the INRAM profile folder. Started FF again (the command used by my window manager shortcut is /usr/lib/firefox-esr/firefox-esr --ProfileManager --new-instance%u, which shows me the profile choice window) choosing INRAM profile (all other windows of other profiles being left intact), tried to open the *script* URL (which i took from the source code i had opened in a JS profile window), and FF asked me where to save the file - in other words, it found the domain that should be blocked.

3. I tried to open that script URL in the NOJS profile, which uses only pages that can be completely (or acceptably) used without javascript. But it found the script too! I did not expect that.

/-:

So are you saying the only way it DOESNT load the unwanted page is if you only open FF with the INRAM profile, with no other FF profile windows having been loaded since boot?

Awwww... that is a really sad discovery (except for the file organization tip). But it will do, I guess. Let me test it...

Note: i am still puzzled to understand how a brand new profile had not opened the unwanted parts... i will do that test again (from zero, since i immediatelly deleted the INRAM profile files created)

First, i want the page. I just do not want some parts of it - from a specific domain.

If you meant "no other FF profile windows" of *that* profile, INRAM, that is what i tried to say. But i repeated the test with these commands or steps:

1. all INRAM windows are closed
2. cd /dev/shm/.inram
3. rm -fr * .* > /dev/zero # /dev/zero just to be silent
4. copied the unwanted script URL
5. clicked in the firefox icon with the command i said before
6. doubleclicked in the inram profile to open it
7. opened a private window and asked it to load the copied URL -> worked
8. closed the private window, opened the copied URL in the normal window -> also worked, of course

So, i do not know how to explain what happened in #7 > step 1. It happened differently now. Two times - i repeat the steps i just described here.

So, the conclusion for this thread is "we have to explicitly put all subdomains in /etc/hosts" ? Something with a wildcard is the first basic idea that i am surprised if it does not exist.

Ah I see. I too thought maybe globbing could work.

If your goal is adblocking have you thought of just running a pi hole?

1 members found this post helpful.

As root, i edited the /etc/hosts file, adding ' page2.gsa.com' to the line where gsa.com is. After saving the file, i "cachelessly" (although i am still not sure that my "cacheless firefox bypasses its DNS cache) reloaded the page with some unwanted contents. It was clean.

Unless any of you want to say something else of what i imagined, i may soon consider this thread as closed.

Thanks to everyone

Pi hole? Mmm... much interesting! I never heard about them. But with that solution, i am satisfied, for now.
(-:o

It is used as a dns caching/ad blocking server. You can run it on many versions of Linux, usually on a raspberry pi. It provides network wide adblocking.

http://https://pi-hole.net/

1 members found this post helpful.

Are you using a proxy?

Simple ping to http://badsite should fail if hosts is correct. dig or nslookup to badsite will fail too.

Use 0.0.0.0 instead of localhost.

I use a good hosts file on almost all systems.

1 members found this post helpful.