Dnsleaktest puzzle

[Volt]

Results: Two DNS resolvers, my ISP and WoodyNet.

I also experience "Good Signature" failure when using Google DNS for some reason. Switching to Quad9 or Cloudflare fixes this issue. However, sometimes Quad9 also fails in some (often random) tests on dnscheck.tools.

 

[NoLight]

Thank you, I'll try that. However in your last paragraph, I don't see any toggle for ECS in the router GUI screenshots I posted and I don't remember (nor have any intention of) enabling it?

You had put DNS 9.9.9.11 in that first post, which is the ECS server.

 

[Zarrow]

I've done a factory reset - while powered on, held the Reset button down for >5 seconds and let the router reboot. Everything went back to the settings that it came with out of the box, apart from the Merlin FW, of course.

I reconfigured it to the settings shown in post #3, i.e. DoT Quad9. All the leaktest tools showed my ISP as DNS resolver. Netstat-NAT showed everything going over HTTPS, no mention of 853. EXACTLY the same results as in my previous posts.

In addition, if I set my browser to use Cloudflare DoH, then dnsleaktest shows Cloudflare as the ISP. That seems to indicate that DNS Director is not working.

Then I changed the WAN DNS over TLS to Cleanbrowsing 1 & 2 (security). Same Cleanbrowsing servers in WAN DNS Server section, no servers defined in LAN DHCP DNS. Now ALL the leaktest tools show Cleanbrowsing servers as the only DNS resolvers. Success!... Errr, not quite. Still showing Cloudflare as the resolver in the aforementioned browser with DoH set to Cloudflare. On dnscheck.tools (in another browser with no DoH) I get the Cleanbrowsing DNS resolvers, but still three red crosses against 'Good signature' as in post #18.

Strangely, Netstat and System Log>Connections are still showing only 443's, no 853's at all.

TL,DR: DoT works with Cleanbrowsing but not Quad9. DNS Director doesn't work. Can't get 853's to appear in network monitoring tabs.

 

[dave14305]

Can't get 853's to appear in network monitoring tabs

I don’t think you will see DoT connections originating from the router in the netstat-nat output because those connections don’t get NATted. Learn to use tcpdump like I suggested in post #14 and prove what the router is sending out. Quad9 definitely works with DoT on the router on 388.4 as a comparison.

 

[Zarrow]

I don’t think you will see DoT connections originating from the router in the netstat-nat output because those connections don’t get NATted. Learn to use tcpdump like I suggested in post #14 and prove what the router is sending out. Quad9 definitely works with DoT on the router on 388.4 as a comparison.

You're right about those connections not getting NATed. If I look at Netstat without the NAT I can see 853's in the requests from my WAN IP.

 

[Caesar the Dictator]

@Zarrow Oh my bad, sorry for wasting your time. We can monitor the name queries of the router itself (all your clients according to the scenario suggested to you in this thread) in the Netstat-NAT/Show only NAT to router itself section (WAN IP to x.x.x.x:53/853).

In addition, if I set my browser to use Cloudflare DoH, then dnsleaktest shows Cloudflare as the ISP. That seems to indicate that DNS Director is not working.

DNS director currently redirects, for example, 8.8.8.8:53 queries of Termux (Android app) to the dns.quad9.net:853 you have set to the router itself, blocking it if dns.google:853 is set to the private DNS address of your tablet. But it leaves the DoH/DNSCrypt (mostly:443) as it is.

Are you currently using the Quad9 server you set to WAN/DNS-over-TLS with DoH disabled in your browser, or are you still seeing your ISP's IP address in the tests?

 

[Zarrow]

@Zarrow Oh my bad, sorry for wasting your time. We can monitor the name queries of the router itself (all your clients according to the scenario suggested to you in this thread) in the Netstat-NAT/Show only NAT to router itself section (WAN IP to x.x.x.x:53/853).

Sorry, but now I'm really confused by this Netstat-NAT output. If I try to put the WAN IP as source and router IP as destination and tick Show only NAT to router itself, I get nothing listed in the Diagnose output box. Same if I swap source and destination.
If I set the source as my client, destination not set, then I get output of the form:
TCP Client local IP:random port Router local IP:80 TIME-WAIT
UDP Client local IP:random port Router local IP:53 ASSURED or UNREPLIED

DNS director currently redirects, for example, 8.8.8.8:53 queries of Termux (Android app) to the dns.quad9.net:853 you have set to the router itself, blocking it if dns.google:853 is set to the private DNS address of your tablet. But it leaves the DoH/DNSCrypt (mostly:443) as it is.

My Android phone will not allow me to set a Private DNS as dns.google:853. It will accept dns.google. If I then do a leaktest on the phone, all of the DNS resolvers are from Google, not the provider I have specified in DoT settings in the router, whether that be Cleanbrowsing or Quad9. DNS Director is clearly not working in my case.

Are you currently using the Quad9 server you set to WAN/DNS-over-TLS with DoH disabled in your browser, or are you still seeing your ISP's IP address in the tests?

When I use Quad9 servers in DoT I always get my ISP's IP (and sometimes WoodyNet in addition) listed as resolvers in the leaktest tools.
When I use Cleanbrowsing servers in DoT I get only Cleanbrowsing resolvers listed in the leaktests.

 

[Zarrow]

Install tcpdump from Entware and watch the DNS traffic on the WAN interface. Look for any plain port 53 DNS and then DoT over port 853 during your leak tests.

opkg update
opkg install tcpdump
tcpdump -i $(nvram get wan0_ifname) -pnv dst port 53
tcpdump -i $(nvram get wan0_ifname) -pnv tcp and dst port 853

I've now installed tcpdump. But when I issue either of those commands you listed above via SSH to the router and surf around a few websites I get:

"tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel"

If I use tcpdump -i eth0 -n -c 10
and run a leaktest I get output of the form:
"listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:22:21.899265 PPPoE [ses 0xdf06] IP [my WAN IP].38114 > [Cleanbrowsing server].853: Flags [.], ack 3132362490, win 501, options [nop,nop,TS val 554578970 ecr 406365443,nop,nop,sack 1 {304:1099}], length 0"
... and many other lines including port 853.

But oddly, if I specify the port thus: tcpdump -i eth0 -n -c10 port 853
I get
"listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel"
Can't reconcile that - port 853 is clearly being used as evidenced by the response to the previous command.

 

[dave14305]

DNS Director is clearly not working in my case.

DNS Director doesn’t block DoT from clients if the DNS Director destination is known to (or could) support DoT (Custom 1-3, Router, Quad9, Cleanbrowsing).

Can't reconcile that - port 853 is clearly being used as evidenced by the response to the previous command.

If you have PPPoE, maybe you need to use interface ppp0 instead of eth0?

 

[Caesar the Dictator]

Sorry, but now I'm really confused by this Netstat-NAT output. If I try to put the WAN IP as source and router IP as destination and tick Show only NAT to router itself, I get nothing listed in the Diagnose output box. Same if I swap source and destination.
If I set the source as my client, destination not set, then I get output of the form:
TCP Client local IP:random port Router local IP:80 TIME-WAIT
UDP Client local IP:random port Router local IP:53 ASSURED or UNREPLIED

Don't add any address to the destination.

My Android phone will not allow me to set a Private DNS as dns.google:853. It will accept dns.google. If I then do a leaktest on the phone, all of the DNS resolvers are from Google, not the provider I have specified in DoT settings in the router, whether that be Cleanbrowsing or Quad9. DNS Director is clearly not working in my case.

Yeah, it's actually dns.google. This is a very strange issue you are having. In firmware version 3004, when the DNS director is active, WAN DNS Setting/DNS Privacy Protocol shows the following warning colored yellow.

DNS Director is enabled - anything configured there to something other than No Redirection or Router will bypass DNS Privacy servers.

Do you also have the same warning?

 

[Zarrow]

DNS Director doesn’t block DoT from clients if the DNS Director destination is known to (or could) support DoT (Custom 1-3, Router, Quad9, Cleanbrowsing).

That's pretty counter-intuitive. I thought the whole point of DNS Director is to force the clients to use the servers set in DNS-over-TLS (if Router is selected).

If you have PPPoE, maybe you need to use interface ppp0 instead of eth0?

Good call! The command
tcpdump -i ppp0 -n -c 10 port 853
does output a load of queries to port 853.
That's with Cleanbrowsing, and the leak testers all show the expected DNS resolvers.

I changed The DNS-over-TLS servers to Quad9 and ran the same tcpdump command. Again, lots of 853's going to the Quad9 server IPs. However, all the leak testers are still (evidently incorrectly) identifying the resolvers as including my ISP's server when using Quad9. It seems that there's something weird going on between Quad9 and these leak testing services. I think I'll stick to Cleanbrowsing.

 

[Zarrow]

Don't add any address to the destination.

I'll just use tcpdump from now on, thanks.

Yeah, it's actually dns.google. This is a very strange issue you are having. In firmware version 3004, when the DNS director is active, WAN DNS Setting/DNS Privacy Protocol shows the following warning colored yellow.

Do you also have the same warning?

No warning.

 

[dave14305]

I thought the whole point of DNS Director is to force the clients to use the servers set in DNS-over-TLS (if Router is selected).

To elaborate, it will reject the client DoT request if the destination doesn’t match the selected DNS Director mode IP. See the generated iptables rules with:

iptables-save -c | grep DNSF

 

[Caesar the Dictator]

No warning.

If DNS director is active and no warning is expected behavior in firmware 3006, then there is no problem. Otherwise it means that DNS director is not active.

 

[Zarrow]

To elaborate, it will reject the client DoT request if the destination doesn’t match the selected DNS Director mode IP. See the generated iptables rules with:

iptables-save -c | grep DNSF

Here's the output from the above command:

DNSFILTER - [0:0]
[956:72963] -A PREROUTING -i br+ -p udp -m udp --dport 53 -j DNSFILTER
[0:0] -A PREROUTING -i br+ -p tcp -m tcp --dport 53 -j DNSFILTER
[956:72963] -A DNSFILTER -i br0 -j RETURN
[0:0] -A DNSFILTER -i br0 -j RETURN
[0:0] -A DNSFILTER -i br0 -j RETURN
[0:0] -A DNSFILTER -j DNAT --to-destination [Router local IP]
DNSFILTER_DOT - [0:0]
[0:0] -A FORWARD -i br+ -p tcp -m tcp --dport 853 -j DNSFILTER_DOT
[0:0] -A DNSFILTER_DOT ! -d [Router local IP]/32 -j REJECT --reject-with icmp-port-unreachable

Does it look okay?

 

[Zarrow]

One last thing: I decided to look for any activity on port 53. Here's what I saw when running a leak test with Quad9 DNS:

tcpdump -i ppp0 -n -c 10 port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
08:59:59.431193 IP [WAN IP].57621 > 9.9.9.9.53: 35166+ A? dns.msftncsi.com. (34)
08:59:59.433986 IP 9.9.9.9.53 > [WAN IP].57621: 35166 1/0/0 A 131.107.255.255 (50)
09:00:59.585699 IP [WAN IP].43757 > 9.9.9.9.53: 32420+ A? dns.msftncsi.com. (34)
09:00:59.596185 IP 9.9.9.9.53 > [WAN IP].43757: 32420 1/0/0 A 131.107.255.255 (50)
... repeated many times

Why is there still traffic on port 53 and why is it directed to a Microsoft DNS server? My PC is running Ubuntu, no Wine, no VM, no Edge, no login to any MSFT sites, no reason at all to contact that server. My phone, the only other client, is Android and was idle at the time.

 

[dave14305]

Does it look okay?

No, there’s something odd about all those RETURN rules, which should be only created for Guest networks or other multi-LAN networks. So yes, DNS Director is broken. What networks have you created in the GUI?

Why is there still traffic on port 53 and why is it directed to a Microsoft DNS server?

It’s the router doing an internet health check by querying a test domain to your chosen DNS server (Quad9).

 

[Zarrow]

No, there’s something odd about all those RETURN rules, which should be only created for Guest networks or other multi-LAN networks. So yes, DNS Director is broken. What networks have you created in the GUI?

It’s the router doing an internet health check by querying a test domain to your chosen DNS server (Quad9).

It's a very simple single LAN, no VLANs, no switches, no Mesh, no Guest Network. My phones and PC connect by 5GHz or 2.4GHz WiFi, my TV and another box (powered off at the time of the test) on ethernet cables. IPs are assigned by DHCP, no static IPs used. Static routes are disabled. LAN Switch Control > Spanning Tree Protocol is enabled (default). No port forwarding, just one port trigger. Are the following VLAN settings correct? (I didn't alter them from the defaults):

 

[dave14305]

It's a very simple single LAN, no VLANs, no switches, no Mesh, no Guest Network.

Try running the get_mtlan command and see if the output makes any sense.

I ran into similar behavior on stock firmware, but wouldn’t have expected it to break Merlin’s original DNS Director implementation.

VPN Director - stock asus firmware.

Mmmm...no. It was in Asus firmware for a while but was removed. Something to do with the naming/copyright infringement? Guess they just removed it from the gui but left the functionality. DNSFilter was renamed to DNS Director in the Asus-Merlin firmware: 388.1 (3-Dec-2022) firmware - CHANGED...

www.snbforums.com

 

[Zarrow]

Try running the get_mtlan command and see if the output makes any sense.

I ran into similar behavior on stock firmware, but wouldn’t have expected it to break Merlin’s original DNS Director implementation.

VPN Director - stock asus firmware.

Mmmm...no. It was in Asus firmware for a while but was removed. Something to do with the naming/copyright infringement? Guess they just removed it from the gui but left the functionality. DNSFilter was renamed to DNS Director in the Asus-Merlin firmware: 388.1 (3-Dec-2022) firmware - CHANGED...

www.snbforums.com

get_mtlan
|-enable:[1]
|-prio:[0]
|-vid:[0]
|-port_isolation:[0]
|-name:[DEFAULT]
|-createby:[WEB]
|-*Network:
|--IPv4:
|-idx:[0]
|-ifname:[br0]
|-br_ifname:[br0]
|-addr:[192.168.0.1]
|-subnet:[192.168.0.0]
|-netmask:[255.255.255.0]
|-prefixlen:[24]
|-dhcp_enable:[1]
|-dhcp_min:[192.168.0.100]
|-dhcp_max:[192.168.0.254]
|-dhcp_lease:[86400]
|-domain_name:[]
|-dns:[][]
|-wins:[]
|-dhcp_res:[0]
|-dhscp_res_idx:[0]
|-dot_enable:[1]
|-dot_tls:[1]
|--IPv6:
|-v6_enable:[0]
|-v6_autoconf:[0]
|-addr6:[]
|-dhcp6_min:[]
|-dhcp6_max:[]
|-dns6:[][][]
|-*SDN Feature Index/Switch:
|-sdn_idx:[0]
|-apg_idx:[0]
|-vpnc_idx:[0]
|-vpns_idx:[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
|-dnsf_idx:[0]
|-urlf_idx:[0]
|-nwf_idx:[0]
|-cp_idx:[0]
|-gre_idx:[0][0][0][0][0][0][0][0]
|-fw_idx:[0]
|-killsw_sw:[0]
|-ahs_sw:[0]
|-wan_idx:[0]
|-ppprelay_sw:[0]
|-wan6_idx:[0]
|-mtwan_idx:[0]
|-mswan_idx:[0]
---------------------------------------
|-enable:[1]
|-prio:[0]
|-vid:[0]
|-port_isolation:[0]
|-name:[MAINBH]
|-createby:[WEB]
|-*Network:
|--IPv4:
|-idx:[0]
|-ifname:[br0]
|-br_ifname:[br0]
|-addr:[192.168.0.1]
|-subnet:[192.168.0.0]
|-netmask:[255.255.255.0]
|-prefixlen:[24]
|-dhcp_enable:[1]
|-dhcp_min:[192.168.0.100]
|-dhcp_max:[192.168.0.254]
|-dhcp_lease:[86400]
|-domain_name:[]
|-dns:[][]
|-wins:[]
|-dhcp_res:[0]
|-dhscp_res_idx:[0]
|-dot_enable:[1]
|-dot_tls:[1]
|--IPv6:
|-v6_enable:[0]
|-v6_autoconf:[0]
|-addr6:[]
|-dhcp6_min:[]
|-dhcp6_max:[]
|-dns6:[][][]
|-*SDN Feature Index/Switch:
|-sdn_idx:[1]
|-apg_idx:[1]
|-vpnc_idx:[0]
|-vpns_idx:[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
|-dnsf_idx:[0]
|-urlf_idx:[0]
|-nwf_idx:[0]
|-cp_idx:[0]
|-gre_idx:[0][0][0][0][0][0][0][0]
|-fw_idx:[0]
|-killsw_sw:[0]
|-ahs_sw:[0]
|-wan_idx:[0]
|-ppprelay_sw:[0]
|-wan6_idx:[0]
|-mtwan_idx:[0]
|-mswan_idx:[0]
---------------------------------------
|-enable:[1]
|-prio:[0]
|-vid:[0]
|-port_isolation:[0]
|-name:[MAINFH]
|-createby:[WEB]
|-*Network:
|--IPv4:
|-idx:[0]
|-ifname:[br0]
|-br_ifname:[br0]
|-addr:[192.168.0.1]
|-subnet:[192.168.0.0]
|-netmask:[255.255.255.0]
|-prefixlen:[24]
|-dhcp_enable:[1]
|-dhcp_min:[192.168.0.100]
|-dhcp_max:[192.168.0.254]
|-dhcp_lease:[86400]
|-domain_name:[]
|-dns:[][]
|-wins:[]
|-dhcp_res:[0]
|-dhscp_res_idx:[0]
|-dot_enable:[1]
|-dot_tls:[1]
|--IPv6:
|-v6_enable:[0]
|-v6_autoconf:[0]
|-addr6:[]
|-dhcp6_min:[]
|-dhcp6_max:[]
|-dns6:[][][]
|-*SDN Feature Index/Switch:
|-sdn_idx:[2]
|-apg_idx:[2]
|-vpnc_idx:[0]
|-vpns_idx:[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
|-dnsf_idx:[0]
|-urlf_idx:[0]
|-nwf_idx:[0]
|-cp_idx:[0]
|-gre_idx:[0][0][0][0][0][0][0][0]
|-fw_idx:[0]
|-killsw_sw:[0]
|-ahs_sw:[0]
|-wan_idx:[0]
|-ppprelay_sw:[0]
|-wan6_idx:[0]
|-mtwan_idx:[0]
|-mswan_idx:[0]
---------------------------------------
|-enable:[1]
|-prio:[0]
|-vid:[0]
|-port_isolation:[0]
|-name:[MAINFH]
|-createby:[WEB]
|-*Network:
|--IPv4:
|-idx:[0]
|-ifname:[br0]
|-br_ifname:[br0]
|-addr:[192.168.0.1]
|-subnet:[192.168.0.0]
|-netmask:[255.255.255.0]
|-prefixlen:[24]
|-dhcp_enable:[1]
|-dhcp_min:[192.168.0.100]
|-dhcp_max:[192.168.0.254]
|-dhcp_lease:[86400]
|-domain_name:[]
|-dns:[][]
|-wins:[]
|-dhcp_res:[0]
|-dhscp_res_idx:[0]
|-dot_enable:[1]
|-dot_tls:[1]
|--IPv6:
|-v6_enable:[0]
|-v6_autoconf:[0]
|-addr6:[]
|-dhcp6_min:[]
|-dhcp6_max:[]
|-dns6:[][][]
|-*SDN Feature Index/Switch:
|-sdn_idx:[3]
|-apg_idx:[3]
|-vpnc_idx:[0]
|-vpns_idx:[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
|-dnsf_idx:[0]
|-urlf_idx:[0]
|-nwf_idx:[0]
|-cp_idx:[0]
|-gre_idx:[0][0][0][0][0][0][0][0]
|-fw_idx:[0]
|-killsw_sw:[0]
|-ahs_sw:[0]
|-wan_idx:[0]
|-ppprelay_sw:[0]
|-wan6_idx:[0]
|-mtwan_idx:[0]
|-mswan_idx:[0]
---------------------------------------

How's that looking?