Send DNS queries to Stuby after Adblock filter

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi,

I wanna send the DNS requests to Stuby (port 5453) after the filter of Adblock wich is the service that receives the requests from DNS standard port 53.

Anybody knows how can I set up Adblock to do this?

Thanks

2

I thought dnsmasq received it...?

...but nonetheless, you receive an NXDOMAIN for an ad domain...so what request is there to pass?

3

I believe OP means the queries which are not classified as ads.

1 Like
4

Yes, that is correct
Sorry for the error in the explanation

5

So you just want to redirect the remaining ad-free urls to stubby!?

edit /etc/config/dhcp:

add under section "config dnsmasq" the following line

    list server '127.0.0.1#5453'

restart dnsmasq with: /etc/init.d/dnsmasq restart

2 Likes
6

I done but when I check Stubby in the URL https://1.1.1.1/help shows me that the DoT is not working

image

I've not made any changes of the Stubby default setup.

What could I do to solve it?

Regards

7

Because your browser isn't using DoT, your router is.

You would verify your router makes encrypted requests to 1.1.1.1. You can use tcpdump to look at packets leaving your WAN for 1.1.1.1.

8

Thank you

I've enabled the Secure DNS lookups in Chrome

image
image890×223 15.6 KB

and now it detects TLS support.

image

9

:+1:

:bulb: (And to be clear, this means your browser is doing lookups for your DNS requests now, not the OpenWrt...meaning, no Adblock.)

10

Sorry, I don´t understand this

I've got running Ublock Origin. You mean that with Ublock the DNS requests don't go to OpenWRT?

11

I am uncertain how a plugin would interact with the program's DoT setting...nor how an unblocked encrypted DNS on the browser and an Ablocked unencrypted DNS on the plugin (as OpenWrt would do the DoT) would behave. This is likely a question for the Chrome folks.

(I honestly wasn't aware that extension needed to perform DNS lookups anyway.)

12

The thing is you can do name resolution on every level. On OS level, application level and infrastructure level (routers, servers/proxies, and so on).
If your browser (or a plugin of your browser) is doing the work you can test dns encryption on application level (your browser).
If it's done on OS level your browser isn't doing DNS resolution anymore. As long you are not installing dnscrypt, bind, stubby or any other DNS application, your OS is not encrypting any DNS request. So you can install it either on OS directly or on your (OpenWrt-)router.
As a result of that said above testing always has to be done on that level you are implementing your DNS solution. If you run stubby on OpenWrt you have to test on OpenWrt.
Use tcpdump for that on OpenWrt (console):

tcpdump -i eth0 udp port 53

eth0=wan interface; it's different on every router, search and replace it accordingly.

1 Like
13

Thank you for the explanation

I didn't know that DNS request could come from apps or even OS.

I guess it isn't any way to redirect all these requests to the router, is it?

14

You did originally direct them to the router, then you turned on DoT in Chrome...because you wanted to see a website say you're using it.

If you mean DoT over LAN...I don't know if there's such an implementation.

15

Yes there are ways to do so. Just short and quick:

  1. Make sure your OS is getting your Routers IP as the only DNS IP. This is usually done by having DHCP enabled in e. g. Windows Network settings. The standard behaviour of Windows is DHCP. So nothing to do there as long as you have only one router handing out DHCP on your LAN.

  2. Disable/Remove any plugin doing DNS resolution in your Browser.

  3. Block any DNS traffic from LAN going out to WAN (OpenWrt Firewall; Ports: 53, 853).

    config rule
     option name 'Block-WAN-DNS'
     option src 'lan'
     option target 'REJECT'
     option proto 'tcp udp'
     option dest_port '53 853'
     option dest 'wan

  4. If you are paranoid and not trusting any android device in your lan add that in addition to your firewall:

    config rule
     option name 'Block-8888'
     option src 'lan'
     option dest 'wan'
     option proto 'all'
     option dest_ip '8.8.8.8 8.8.4.4'
     option family 'ipv4'
     option target 'REJECT'

I hope I didn't forget anything.

16

It would be better to hijack the rogue NS queries than drop them. Will save the time that resolver will time out.
Also it's not a good idea to block all protocols to GoogleDNS. Many apps use it to verify network connectivity.

2 Likes
17

Thanks both of your for the answers

Unfortunately, I don´t know what are rogue NS queries and much less how to set up them. I'll google it

18

Ah ... if I think about yes, redirect to own DNS should be faster indeed. :smiley: ... Thx for this hint.
Never had any issues blocking all. And I guess it was just a mistake blocking any in that rule. But I'm sure I'm not a casual user.

19

They are NS queries that are not sent to the designated nameserver, in your case OpenWrt.

1 Like