3 ms·

No, DNS sinkholes silently replace queries by a valid internal IP - to JavaScript, it looks like the resource is loading, but the webbrowser actually just displ

No, DNS sinkholes silently replace queries by a valid internal IP - to JavaScript, it looks like the resource is loading, but the webbrowser actually just displays whitespace instead of the app. Check for example this page [1] - if you run AdBlock, it will be detected. My page just looks void of Ads with pfblockerng [2]. It works inside Apps (Android etc.) and games or youtube videos, too. There are ways to get around this, like e.g. hardcoding IPs that are not known to serve Ads, but this needs additional work and 99% of ads don't do this. Benefits of router based DNS sinkholes: - cannot be detected by websites with anti-adblock scripts - no memory consumption on clients - fewer web browser plug-ins needed - lower device CPU utilization from AdGuard PC/Android apps, uBlock extensions etc. - protects all network devices without requiring extra work - browser, software and OS independent - device and PC independent. - implements redundancy should users remove/disable browser plug-ins [1]: https://next-episode.net/ https://next-episode.net/ [2]: https://imageupload.io/i/pL0x1yM8eC https://imageupload.io/i/pL0x1yM8eC

Thorrez 4y ago
It's probably still somewhat detectable by noticing that all requests to ad domains are taking a long time to load while requests to non-ad domains are loading quickly. There will be false positives and false negatives, but I think it can be pretty accurate for people who have good network speed.
- Helmut10001 4y ago
  Requests to ad domains don't take longer - they're faster, since 0.0.0.0 (the sinkhole) will answer the query, instead of some internet Ad IP.
  - Thorrez 4y ago
    Then the request will fail right, since the https cert doesn't match? Or are you installing a custom root CA? Loading faster is also probably detectable, especially if there's some request that the server intentionally replies slowly to to aid detection.
    - Helmut10001 4y ago
      You're right, in this case the https will fail and this will indeed (mostly) slow down loading of Ads. I was wrong - although, personally, I do not observe slower loading times for pages, even though some ad-urls are failing. There are indeed some very rare pages (like zdf.de) that won't load at all because they have a very aggressive ad/surveillance checking.
LunaSea 4y ago
So it's incredibly easy to detect.
- Helmut10001 4y ago
  Care to explain? Give me an address that runs an anti-ad-blocker and I show you it won't work.
  - redleader55 4y ago
    Someone determined enough to serve you ads through a DNS sinkhole could do something like this: the page injects the ads using js and waits for a pingback that is triggered after the ad is loaded. On a timer, if the ping was not received, the page can inject another ad with hard-coded ip address, instead of DNS. The reason why this does not happen is that companies understand that someone who hates ads so much they are willing to deploy an ad blocker, a DNS sinkhole, etc will probably not click on an ad either way.
    - Helmut10001 4y ago
      Also, note that pfblocker-ng contains lists of millions of (automatically updated) IPs known to serve Ads (or malicious content), redirecting those, too. So unless you are willing to switch precious IPs for your hardcoded IP-Ad-Serving Servers, injection through Javascript won't work either. The only actual direct consequence to clients I have noticed is that if you directly want to resolve Blocked-Ad-Links, it won't work - e.g., Google usually displays some "Ad"-Links first as results - clicking these won't get you anywhere. For my private LAN users, I think this is a good lecture to have - realizing that you're bullied into clicking valid-looking links that are instead Ads, from people that pay others to distract you from what you were actually looking for, or distort the natural ranking by paying for being ranked first. I have a printout at our house for visitors who complain about this: They can manually set their DNS to 8.8.8.8 and my router won't interfere (it could, but I found spoofing direct requests to Google's DNS a bit too much).

Thorrez 4y ago

It's probably still somewhat detectable by noticing that all requests to ad domains are taking a long time to load while requests to non-ad domains are loading quickly. There will be false positives and false negatives, but I think it can be pretty accurate for people who have good network speed.

Helmut10001 4y ago
Requests to ad domains don't take longer - they're faster, since 0.0.0.0 (the sinkhole) will answer the query, instead of some internet Ad IP.
- Thorrez 4y ago
  Then the request will fail right, since the https cert doesn't match? Or are you installing a custom root CA? Loading faster is also probably detectable, especially if there's some request that the server intentionally replies slowly to to aid detection.
  - Helmut10001 4y ago
    You're right, in this case the https will fail and this will indeed (mostly) slow down loading of Ads. I was wrong - although, personally, I do not observe slower loading times for pages, even though some ad-urls are failing. There are indeed some very rare pages (like zdf.de) that won't load at all because they have a very aggressive ad/surveillance checking.

LunaSea 4y ago

So it's incredibly easy to detect.

Helmut10001 4y ago
Care to explain? Give me an address that runs an anti-ad-blocker and I show you it won't work.
- redleader55 4y ago
  Someone determined enough to serve you ads through a DNS sinkhole could do something like this: the page injects the ads using js and waits for a pingback that is triggered after the ad is loaded. On a timer, if the ping was not received, the page can inject another ad with hard-coded ip address, instead of DNS. The reason why this does not happen is that companies understand that someone who hates ads so much they are willing to deploy an ad blocker, a DNS sinkhole, etc will probably not click on an ad either way.
  - Helmut10001 4y ago
    Also, note that pfblocker-ng contains lists of millions of (automatically updated) IPs known to serve Ads (or malicious content), redirecting those, too. So unless you are willing to switch precious IPs for your hardcoded IP-Ad-Serving Servers, injection through Javascript won't work either. The only actual direct consequence to clients I have noticed is that if you directly want to resolve Blocked-Ad-Links, it won't work - e.g., Google usually displays some "Ad"-Links first as results - clicking these won't get you anywhere. For my private LAN users, I think this is a good lecture to have - realizing that you're bullied into clicking valid-looking links that are instead Ads, from people that pay others to distract you from what you were actually looking for, or distort the natural ranking by paying for being ranked first. I have a printout at our house for visitors who complain about this: They can manually set their DNS to 8.8.8.8 and my router won't interfere (it could, but I found spoofing direct requests to Google's DNS a bit too much).