I add this in /jffs/configs/dnsmasq.conf.add, then service restart_dnsmasq. I can see the line is present in /tmp/etc/dnsmasq.conf. Is this the correct way?
Unfortunately I see query[type=65] gets resolved.
Diversion Seeing Ads (Mobile/Tablets)
- Thread starter Background
- Start date
-
- Tags
- ios mobile ads sponsored
Unfortunately I see query[type=65] gets resolved.
SomeWhereOverTheRainBow
Part of the Furniture
Maybe you need to reboot devices as well so it refresh their dns. or manually refresh dns on devices.
I add another entry with specific domain before the wildcard entry.
Code:
dns-rr=aviationweather.gov,65,
dns-rr=*,65,From dnsmasq log, it seems with specific domain, it works. But the wildcard one seems not working.
Code:
Jul 19 13:48:18 dnsmasq[7134]: 109 192.168.1.21/57139 query[type=65] aviationweather.gov from 192.168.1.21
Jul 19 13:48:18 dnsmasq[7134]: 109 192.168.1.21/57139 config aviationweather.gov is type=65
Jul 19 13:48:18 dnsmasq[7134]: 110 192.168.1.21/53918 query[A] aviationweather.gov from 192.168.1.21
Jul 19 13:48:18 dnsmasq[7134]: 110 192.168.1.21/53918 forwarded aviationweather.gov to 127.0.0.1
Jul 19 13:48:18 dnsmasq[7134]: 110 192.168.1.21/53918 reply aviationweather.gov is 23.72.44.14
Jul 19 13:48:18 dnsmasq[7134]: 111 192.168.1.21/54636 query[type=65] firebaselogging-pa.googleapis.com from 192.168.1.21
Jul 19 13:48:18 dnsmasq[7134]: 111 192.168.1.21/54636 forwarded firebaselogging-pa.googleapis.com to 127.0.0.1Update:
I try to figure out how wildcard is supported here but failed.
Code:
dns-rr=*,65,
dns-rr=.com,65,
dns-rr=*.com,65,
dns-rr=apple.com,65,
dns-rr=*apple.com,65,
dns-rr=.apple.com,65,
dns-rr=*.apple.com,65,
Jul 19 15:59:46 dnsmasq[6222]: 62 192.168.1.21/49898 query[type=65] captive.apple.com from 192.168.1.21
Jul 19 15:59:46 dnsmasq[6222]: 62 192.168.1.21/49898 forwarded captive.apple.com to 127.0.0.1It works with matching domain.
Code:
dns-rr=*,65,
dns-rr=.com,65,
dns-rr=*.com,65,
dns-rr=apple.com,65,
dns-rr=*apple.com,65,
dns-rr=.apple.com,65,
dns-rr=*.apple.com,65,
dns-rr=captive.apple.com,65,
Jul 19 16:01:56 dnsmasq[22314]: 25 192.168.1.21/64430 query[type=65] captive.apple.com from 192.168.1.21
Jul 19 16:01:56 dnsmasq[22314]: 25 192.168.1.21/64430 config captive.apple.com is type=65
Last edited:
SomeWhereOverTheRainBow
Part of the Furniture
So you would need to know the domains then.
SomeWhereOverTheRainBow
Part of the Furniture
Until Dnsmasq devs add wildcard option to this, It is probably better to do this with your firewall rule since I cannot imagine having to do this with a list of 100000 domains. I doubt Dnsmasq would be able to handle that.
thelonelycoder
Part of the Furniture
Dnsmasq does not support wildcard symbols.
Background
Regular Contributor
Intreseting! I guess there is really no way to block these Ads now other than AdGuard on PI.
I think my Diversion has become damaged though `a ad-blocking to IP 0.0.0.0` all of a sudden I'm sure yesterday it said 192.168.1.1, would this be the Skynet firewall iptables?
I think my Diversion has become damaged though `a ad-blocking to IP 0.0.0.0` all of a sudden I'm sure yesterday it said 192.168.1.1, would this be the Skynet firewall iptables?
SomeWhereOverTheRainBow
Part of the Furniture
Until Simon Kelly decides he wants to tailor a special dnsmasq for Diversion with @thelonelycoders authorization or wants to personally make an easy way to block type 65 traffic, I imagine these queries will continue to allude diversion.
dave14305
Part of the Furniture
If you had Pixelserv before, it would be a 192.168.1.x address. If Pixelserv is now disabled, it would now be 0.0.0.0.
SomeWhereOverTheRainBow
Part of the Furniture
Not only unfeasible, but also potentially unstable since there is no telling how big that block list is. having an addition such as this may really limit how big an already small block list can be supported by dnsmasq. If using DNSmasq to do this type of blocking, we would be better to do a targetted form of blocking. We would need a list of common type 65 domains to minimize the strain on an already potentially over burdened dnsmasq.
SomeWhereOverTheRainBow
Part of the Furniture
Maybe users should test blocking these with pixelserv-tls. Pihole classifies type 65 as a form of https query type. Maybe pixelserv-tls can block them.
The earlier iptables rules can blanket block all DNS query type 65. I have a feeling Instagram/Snapchat/Twitter stories/ads are served from the same domain as their application. I think this is beyond what Diversion or DNS query type 65 can block.
I have no experience with pixelserv-tls. I wonder if the https query refers to port 443 or 8443 type of query, rather than port 53 https DNS query?
SomeWhereOverTheRainBow
Part of the Furniture
The only way to know is to test. As I have no apple products, I do not have a way to test, but if someone is adventurous it may be interesting to see. According to alot of users, Pixelserv-tls blocks too much making apps unusable. It is curious to see if it can block a type 65 query from a domain on the block list.
I am new to pixelserv-tls. I have import Pixelserv CA but not sure how to verify if it is working correctly. After delete the iptables rules, I can see DNS query type 65 gets resolved. By default it is listening on port 80 and 443. I try to change it to port 53 but not accepted. How should I test it?
Code:
Jul 20 16:35:38 RT-AC86U-DBA8 pixelserv-tls[21203]: Listening on :192.168.1.254:443
Jul 20 16:35:38 RT-AC86U-DBA8 pixelserv-tls[21203]: Listening on :192.168.1.254:80
Jul 20 16:36:17 RT-AC86U-DBA8 pixelserv-tls[22270]: pixelserv-tls 2.3.1 (compiled: Apr 17 2021 21:00:13 flags: tfo tls1_3) options: -k 53 -p 53
Jul 20 16:36:18 RT-AC86U-DBA8 pixelserv-tls[22270]: Abort: Address already in use - :*:53SomeWhereOverTheRainBow
Part of the Furniture
It listens on 443 because the https query would travel via ssl 443. Not ssl 53. The query would still initiate on 53. You would need to let it run as is not trying to point it at 53. But you need to make sure domains that are using type 65 queries are located in your blocklist. They would be pointed at the ip of your pixelserv-tls, instead of being pointed at 0.0.0.0
Last edited:
Background
Regular Contributor
I've pixelserv enabled and has never been disabled but noticed it's changed to 0.0.0.0 via WebUI and via PuTTY. Only thing changed is updated to beta 3 + the above IPTable rules.
Turns out I always have pixelserv-tls enabled. But I have never import the certificate. It seems not working. However, I’m not sure if I have get it working correctly. Hopefully others can help to test this out as well.
SomeWhereOverTheRainBow
Part of the Furniture
I can confirm Pihole can block these queries no problem as long as the domain is defined in the blocklist.
They classify the queries as HTTPS, but they use to classify it as other.
They classify the queries as HTTPS, but they use to classify it as other.
Similar threads
| Thread starter | Title | Forum | Replies | Date |
|---|---|---|---|---|
| S | Diversion Diversion - Ads Not Getting Blocked | Asuswrt-Merlin AddOns | 4 | |
| R | Diversion Diversion doesn’t block youtube ads? | Asuswrt-Merlin AddOns | 31 | |
| M | Diversion Reset Diversion's "ads blocked" database? | Asuswrt-Merlin AddOns | 2 |
Similar threads
-
Diversion Diversion - Ads Not Getting Blocked
- Started by SashaSolitaire
- Replies: 4
-
-
Diversion Reset Diversion's "ads blocked" database?
- Started by m m.
- Replies: 2