AdGuard

[XIII]

I think the best you can get with this test using dns level adblocking only (and no ublock origin) is 93%. If anybody can get better with only DNS level Adblocking, please feel free to share your technique or lists.

View attachment 54105

Which website hosts that test?

 

[SomeWhereOverTheRainBow]

Which website hosts that test?

Test Ad Block - Toolz

Looking for an easy way to check the efficiency of your ad blocker?Toolz offers a simple and beautiful design test that allows you to quickly and easily test the performance of current ad/content blocker solution. Intuitive interface makes it easy to navigate and use, and the beautiful design...

d3ward.github.io

 

[XIII]

Thanks!

I wonder how correct that test is.

On my Mac I score 100% on Safari (with AdGuard extension), but only 81% in Firefox (no ad block extension installed). One of the domains that is not blocked is tiktok.com. After manually adding *.tiktok.com to the deny-list of NextDNS, flushing my DNS cache, and clearing the browser cache, the test scores the same 81%; still telling me that TikTok stuff is not blocked. However, in the NextDNS log I do see that the entry is blocked and `nslookup` returns 0.0.0.0.

(The test claims to be compatible with NextDNS, if you don't use block pages, which I indeed don't use)

 

[Tech9]

Alas, not it.

Apple devices may go around your DNS filtering. Try this, Deny List:

 

[Treadler]

Apple devices may go around your DNS filtering. Try this, Deny List:

View attachment 54137

View attachment 54138

Yup, any Apple device with ‘Apple Private Relay’ enabled will ignore any router DNS settings.
Plus, any Apple device with a DNS profile installed will do likewise.

 

[martinr]

Apple devices may go around your DNS filtering. Try this, Deny List:

View attachment 54137

View attachment 54138

Yup, any Apple device with ‘Apple Private Relay’ enabled will ignore any router DNS settings.
Plus, any Apple device with a DNS profile installed will do likewise.

You’re dead right. I should have remembered I’d encountered this problem with Apple devices a while back when turning on Apple Private Relay. Thank you for the reminder.


https://www.snbforums.com/threads/s...all-other-devices-protected.80420/post-784615.

 

[martinr]

I’ve a query/observation, and because it’s come out of playing with the suggestions and advice given in this topic, I decided to put it here rather than start a new thread.

RT-AC68U running Diversion (with pixelserv), Skynet, Unbound. Merlin 386.12.

Router WAN DNS server setting is to Adguard.

DNS Director Global Redirection is set to Router, IP address 192.168.10.1.

I set out to confirm Adguard was indeed being used as my DNS Server.

On my iPad, using the terminal app, Termius, I do indeed see Adguard as my DNS server using nslookup, but it’s the ONLY test that confirms this:

If, in a browser on Windows, Ubuntu or an Apple device, I go to dnsleaktest.com, or 1.1.1.1/help, my DNS server is given as TalkTalk (my ISP).

If I use nslookup in a Windows terminal, and type in a domain I have never visited before, the DNS server address is that of my router, and the answer is invariably listed as non-authoritative:

Similarly, if I use nslookup in an Ubuntu terminal, and type in a domain I have never visited before, the DNS server address comes up as 127.0.0.53, and, again, the answer is invariably listed as non-authoritative:

If I hadn’t seen Adguard listed in Termius on my iPad (top screenshot), I might have been posting saying that despite setting Adguard as my DNS server, my DNS queries are going to my ISP instead. Similarly, I might have asked why, in a terminal, is my router being given as my DNS server, despite Adguard being specified (although, I possibly can see the logic in that).

So, I guess this has taught me - unless I have missed a trick - that one has to be very careful when using tests such as dnsleak and others, and even terminals, before concluding where the DNS queries are really being handled.

I would very much appreciate some expert analysis/corrections/advice on this, please, especially if something really is amiss.

 

[Viktor Jaep]

I’ve a query/observation, and because it’s come out of playing with the suggestions and advice given in this topic, I decided to put it here rather than start a new thread.

RT-AC68U running Diversion (with pixelserv), Skynet, Unbound. Merlin 386.12.

Router WAN DNS server setting is to Adguard.

DNS Director Global Redirection is set to Router, IP address 192.168.10.1.

I set out to confirm Adguard was indeed being used as my DNS Server.

On my iPad, using the terminal app, Termius, I do indeed see Adguard as my DNS server using nslookup, but it’s the ONLY test that confirms this:

View attachment 54163

If, in a browser on Windows, Ubuntu or an Apple device, I go to dnsleaktest.com, or 1.1.1.1/help, my DNS server is given as TalkTalk (my ISP).

If I use nslookup in a Windows terminal, and type in a domain I have never visited before, the DNS server address is that of my router, and the answer is invariably listed as non-authoritative:

View attachment 54164



Similarly, if I use nslookup in an Ubuntu terminal, and type in a domain I have never visited before, the DNS server address comes up as 127.0.0.53, and, again, the answer is invariably listed as non-authoritative:

View attachment 54165


If I hadn’t seen Adguard listed in Termius on my iPad (top screenshot), I might have been posting saying that despite setting Adguard as my DNS server, my DNS queries are going to my ISP instead. Similarly, I might have asked why, in a terminal, is my router being given as my DNS server, despite Adguard being specified (although, I possibly can see the logic in that).

So, I guess this has taught me - unless I have missed a trick - that one has to be very careful when using tests such as dnsleak and others, and even terminals, before concluding where the DNS queries are really being handled.

I would very much appreciate some expert analysis/corrections/advice on this, please, especially if something really is amiss.

You should fire up @eibgrad's old DNSMON script... it usually gives you some pretty good insight on which path lookups are taking...

Tutorial - How to monitor DNS traffic in real-time

The following script allows for real-time monitoring of DNS on the router for the purposes of knowing what DNS servers are in use, and which network interfaces are being used. https://pastebin.com/AGNF8cC8 Overview One of the most difficult aspects of the router for users is managing DNS. DNS...

www.snbforums.com

And this is another one of my troubleshooting fav's:

dnscheck.tools - check your dns resolvers

A tool to test for DNS leaks, DNSSEC validation, and more

dnscheck.tools

 

[dave14305]

On my iPad, using the terminal app, Termius, I do indeed see Adguard as my DNS server using nslookup, but it’s the ONLY test that confirms this:

This is a test of the router, not the iPad. The router (by default) uses the WAN DNS servers. Clients will use the router’s dnsmasq by default. Linux clients usually have a local resolver (e.g. systemd-resolved).

Unbound as your resolver will make your own WAN IP appear in leak tests (your WAN IP does still belong to your ISP). Clients’ queries will never reach AdGuard when Unbound is running.

 

[martinr]

This is a test of the router, not the iPad. The router (by default) uses the WAN DNS servers. Clients will use the router’s dnsmasq by default. Linux clients usually have a local resolver (e.g. systemd-resolved).

Unbound as your resolver will make your own WAN IP appear in leak tests (your WAN IP does still belong to your ISP). Clients’ queries will never reach AdGuard when Unbound is running.

Thanks, Dave.

“Clients’ queries will never reach AdGuard when Unbound is running.” Of course! I mistakenly thought a domain never requested before would be forwarded from Unbound to Adguard. Definitively time to ditch Unbound Manager and start again. I can’t remember learning as much from any topic as the rabbit holes this topic has sent me down.

 

[martinr]

This is a test of the router, not the iPad. The router (by default) uses the WAN DNS servers. Clients will use the router’s dnsmasq by default. Linux clients usually have a local resolver (e.g. systemd-resolved).

Unbound as your resolver will make your own WAN IP appear in leak tests (your WAN IP does still belong to your ISP). Clients’ queries will never reach AdGuard when Unbound is running.

Unbound Manager uninstalled and now dnsleaktest.com does indeed show Adguard as the DNS server. (The results using nslookup in the terminals including Termius, are as they were before uninstalling Unbound.)

So, many thanks. This really has been a really valuable exercise, and it’s not over yet. It’s also proved several laws: the law of Unintended Consequence, Keep it Simple Stupid, Sod’s Law, and if it ain’t broke, don’t fix it. And probably quite a few more.

 

[Tech9]

Definitively time to ditch Unbound Manager and start again.

Perhaps not needed because you already run Diversion.

 

[SomeWhereOverTheRainBow]

I’ve a query/observation, and because it’s come out of playing with the suggestions and advice given in this topic, I decided to put it here rather than start a new thread.

RT-AC68U running Diversion (with pixelserv), Skynet, Unbound. Merlin 386.12.

Router WAN DNS server setting is to Adguard.

DNS Director Global Redirection is set to Router, IP address 192.168.10.1.

I set out to confirm Adguard was indeed being used as my DNS Server.

On my iPad, using the terminal app, Termius, I do indeed see Adguard as my DNS server using nslookup, but it’s the ONLY test that confirms this:

View attachment 54163

If, in a browser on Windows, Ubuntu or an Apple device, I go to dnsleaktest.com, or 1.1.1.1/help, my DNS server is given as TalkTalk (my ISP).

If I use nslookup in a Windows terminal, and type in a domain I have never visited before, the DNS server address is that of my router, and the answer is invariably listed as non-authoritative:

View attachment 54164



Similarly, if I use nslookup in an Ubuntu terminal, and type in a domain I have never visited before, the DNS server address comes up as 127.0.0.53, and, again, the answer is invariably listed as non-authoritative:

View attachment 54165


If I hadn’t seen Adguard listed in Termius on my iPad (top screenshot), I might have been posting saying that despite setting Adguard as my DNS server, my DNS queries are going to my ISP instead. Similarly, I might have asked why, in a terminal, is my router being given as my DNS server, despite Adguard being specified (although, I possibly can see the logic in that).

So, I guess this has taught me - unless I have missed a trick - that one has to be very careful when using tests such as dnsleak and others, and even terminals, before concluding where the DNS queries are really being handled.

I would very much appreciate some expert analysis/corrections/advice on this, please, especially if something really is amiss.

Surprised you just didnt throw

server=/mask.icloud.com/
server=/mask-h2.icloud.com/
server=/mask.apple-dns.net/

or (for newer dnsmasq versions.)

local=/mask.icloud.com/
local=/mask-h2.icloud.com/
local=/mask.apple-dns.net/

in the ole' dnsmasq.conf.add and call it a day.

Methods with pihole discussed here:

https://www.reddit.com/r/pihole/comments/px136i

and https://discourse.pi-hole.net/t/icloud-private-relay/49811/2 .

Preferred DNS control methods are "NXDOMAIN" or "NULL". No-Data responses cause issues.

And with AdGuardHome there are many approaches to dealing with this issue, but one of the more popular is with DNS rewrites.

The method below only rewrites the IP for a "NULL" response.

Another method.. "NXDOMAIN" response.

 

[Toinks]

And with AdGuardHome there are many approaches to dealing with this issue, but one of the more popular is with DNS rewrites.

The method below only rewrites the IP for a "NULL" response.

View attachment 54225

Another method.. "NXDOMAIN" response.

View attachment 54226

In AGH, block iCloud Private Relay in Filters > Blocked services

 

[SomeWhereOverTheRainBow]

In AGH, block iCloud Private Relay in Filters > Blocked services

Awesome, I just now saw that. Either way, it is good to know all methods in case they remove that feature in a future date.