3

For over 10 years I have been using the HOSTS file to block ads and other nasties on both macOS and Windows PCs. (Refer: https://winhelp2002.mvps.org/hosts.htm)

It has worked flawlessly, until the macOS upgrade to Monterey 12.1.

The new behaviour was noticed on both my MacBook Pro (early 2015) and Mac mini (2018).

With Firefox, ads continue to be blocked just as before.

I can now only block ads in Safari (15.2) by using a content blocker e.g. Adblock Plus.

It seems as though Safari on Monterey is ignoring the HOSTS file. I have tried restarts of Safari and the Mac and flushing the DNS cache, all to no avail.

As a test I added www.nytimes.com to the hosts file. On Firefox, the site doesn't appear to exist. Safari opens it as per usual - so it is definitely ignoring HOSTS.

Anyone else noticed this issue?

Update: the issue only occurs when Hide IP address for Trackers and Websites is selected; it does not occur when Hide IP address for Trackers only is selected.

My understanding is that browsers should never ignore HOSTS as they may be required for Intranet and other redirects/blocks.

2
  • Safari is ignoring the much of your DNS (and similar) settings. The DNS is not ignoring hosts. My view: either use Apple hiding and blocking or take things into your own hands (with hosts, VPN, etc.). Don't mix the two.
    – Gilby
    Jan 16, 2022 at 8:24
  • Have you tried disabling the iCloud Private Relay, if it's enabled?
    – Extrawdw
    Jan 17, 2022 at 3:49

2 Answers 2

1

Update: the issue only occurs when Hide IP address for Trackers and Websites is selected; it does not occur when Hide IP address for Trackers only is selected.

As you've observed, "Hide IP address" (which is also known as iCloud Private Relay) is uses a completely separate process for resolving DNS queries.

From the whitepaper:

To protect the privacy of DNS name resolution for all queries sent by the device and prevent such tracking, Private Relay uses Oblivious DNS over HTTPS (ODoH).

ODoH sends DNS queries through the first internet relay, so the DNS server cannot identify the user issuing a query. Each query itself is padded and encrypted using Hybrid Public Key Encryption (HPKE) to help ensure that the first internet relay cannot tell the domain name a user is looking up

Evidently, this process doesn't read the HOSTS file.


My understanding is that browsers should never ignore HOSTS as they may be required for Intranet and other redirects/blocks.

This is also addressed:

If a proxy or ODoH server detects that a specific server name is not a public internet name, it instructs the device to try to access the server directly over the local network. For added protection, the device will never allow direct connections to names that are on the DuckDuckGo known tracker list.

While it appears that you could add a custom domain in your HOSTS file, you cannot modify any domain that resolves on iCloud Private Relay.

One last thing:

If a user has configured custom-encrypted DNS settings using a profile or an app, the DNS server specified will be used instead of ODoH. Safari connections and all unencrypted HTTP connections will also resolve names using the specified DNS server prior to routing through Private Relay.

An unencrypted DNS server provided by a local network or manually edited in Settings (iOS) or System Preferences (macOS) will not be used for iCloud Private Relay traffic.

If you want to provide your own DNS service, you can. This means that a custom DNS service that doesn't resolve those hostnames should work fine.

1
  • Thank you, this provided my quite some clarity. I have a completely different use case (local web development) and disabling iCloud private relay solved the problem. Maybe I will need to research on custom DNS services to use iCloud private relay again... Mar 8 at 9:19
-1

Safari and other browsers often pass your URL to the search engine database which can’t know what you’re trying to block locally.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .