Hijack DNS doesnt

This seems like a dead horse but lets flog it some more .
I followed the instructions to hijack dns which resulted in the following firewall addition

firewall.dns_int.proto='tcp udp'

It doesnt do anything bad it doesnt seem to do anything at all .
I moved my phone to 'vlan3' and in termux did
dig @

Listing connections under Luci shows the phone connected to udp port 53 at

Am I missing something or do I not understand ?

So I guess I answered my own question . tcpdump shows no out bound traffic from the phone to wan at the dns server address . The Luci connection list shows a connection to the wan dns server and a connection to the local dns server . So the wan dns server connection is just internal to my router which is funneling the traffic back to the local dns , right ?

It's hard to say without seeing your local network configuration, but would expect the phone to be sending DNS queries to your gateway ( router ) address, and the router querying external DNS and relaying back to your phone.

Moreover though if you are truly looking for control over DNS (including devices / apps that have inherent DoH ) you might consider a more comprehensive approach of installing / using a combination of https-dns-proxy (enabling the setting to hijack DNS) and BanIP ( adding the blocklist for external DoH servers.)


Of course it does nothing, because you forgot to specify the destination.

Redirection means: redirect from A (source) to B (destination).

You specified the source, but not the destination. Therefore it does not work.

1 Like

I guess that makes sense . This seems to work

config redirect
option target 'DNAT'
option name 'dns-redirect-vlan3'
option family 'ipv4'
option src 'vlan3'
option src_ip '!'
option src_dip '!'
option src_dport '53'
option dest_ip ''
option dest_port '53'

So far no undesirable side affects

According to firewall configuration documentation:

For DNAT, if the dest_ip is not specified, the rule is translated in a redirect rule, otherwise it is a DNAT rule.

According to nftables documentation:


There is a specialized case of Destination NAT called redirection: it is a simple convenience which is exactly equivalent to doing DNAT to the address of the incoming interface.

So, your initial rule, was probably redirecting to some vlan3 local ip and probably your local DNS server is not configured to listen on that interface.

You can either bind your local dns server lo listen on vlan3 interface or manually specify a dest_ip on some interface your local DNS server is listening to.

1 Like

Thanks for clarification. :+1:

1 Like