Tutorial How to monitor DNS traffic in real-time

[eibgrad]

Hi @eibgrad and @ZebMcKayhan. Thank you both for your replies, I think it is fair to say that I am moving from 'did not know that I did not know' to 'knowing that I do not know' but I am still new to this (and v confused).

If I have understood anything it is that using outgoing-interface in Unbound works as far as determining how the DNS requests are sent, but in order to have the replies via the VPN/avoid the WAN there need to be specific routing instructions. If this is correct then it is a matter of how would I determine what these instructions would be and how / where would they go.

There would seem to be at least 3 ways of approaching this - adding rules in VPN director, adding static routes in LAN or editing directly, but I need some guidance on what, how and where. For instance in the wgm link @ZebMcKayhan discusses adding



and above



but what would be the analogous rules in VPN director (assuming this would be the right place. Currently my sole rule is
View attachment 39775
and would the order be relevant.

With regard to my current routes (from ip route)

default via 176.253.204.1 dev eth0
10.8.0.0/24 dev tun15 proto kernel scope link src 10.8.0.4
10.5.6.0/24 dev br0 proto kernel scope link src 10.5.6.1
10.88.0.0/24 dev tun21 proto kernel scope link src 10.88.0.1
127.0.0.0/8 dev lo scope link
176.253.204.0/22 dev eth0 proto kernel scope link src 176.253.204.143
176.253.204.1 dev eth0 proto kernel scope link
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.2

@eibgrad mentioned in #130 above that

For clarity, there is no double NAT. I am connected to my ISP via a Vigor 130 VDSL2 modem (not a router) I have added

Spoiler: wan-start

#!/bin/sh

if [ "$2" = "connected" ]; then
  ifconfig $(nvram get wan"$1"_ifname):1 192.168.2.2
fi

to allow me to check its status from the LAN.

Thanks for the clarification about the 192.168.2.0/24 network. As it turns out, it's not significant to the problem. But when you're trying to diagnose things, stuff like this becomes a mystery.

So now I see you multihomed the WAN w/ that wan-start script.

Given you already did this, I suppose one thing you could do is multihome it again, say as 192.168.3.1 255.255.255.255 ...

if [ "$2" = "connected" ]; then
  ifconfig $(nvram get wan"$1"_ifname):1 192.168.2.2
  ifconfig br0:1 192.168.3.1 netmask 255.255.255.255
fi

... then bind Unbound *outbound* to that IP instead, and finally create a routing rule to route 192.168.3.1 over the VPN.

<192.168.3.1> <blank> OVPN5

 

[eibgrad]

P.S. I updated my previous post to bind 192.168.3.1 to *br0* (the private network), rather than the WAN. It would probably even be more proper to do so in the init-start script, but I suppose wan-start will work too, esp. if you already are using it.

 

[archiel]

P.S. I updated my previous post to bind 192.168.3.1 to *br0* (the private network), rather than the WAN. It would probably even be more proper to do so in the init-start script, but I suppose wan-start will work too, esp. if you already are using it.

Worked perfectly - everything is green (or yellow for dns.msftncsi.com phone home).

Spoiler: Output

AN/LAN IP: x.x.x.x/10.5.6.1

WAN DNS: 127.0.1.1
DHCP DNS: 127.0.1.1
DoT DNS: 1.1.1.1, 1.0.0.1 (Strict)

OVPN5 IP/DNS Config/Redirect Internet: 10.8.1.8/Disabled/VPN Director

Active DNS (Do53/DoT) UDP/TCP Connections
  Do53 (plaintext) routed over the WAN
  DoT (ciphertext) routed over the WAN
  Do53/DoT NOT routed over the WAN (loopback, local, or VPN)

    v-------------- sender ---------------v           v------------- recipient -------------v
udp src=10.5.6.115      dst=10.5.6.1        dport=53  src=10.5.6.1        dst=10.5.6.115
udp src=10.5.6.116      dst=10.5.6.1        dport=53  src=10.5.6.1        dst=10.5.6.116
udp src=10.5.6.120      dst=10.5.6.1        dport=53  src=10.5.6.1        dst=10.5.6.120
udp src=10.5.6.135      dst=10.5.6.1        dport=53  src=10.5.6.11       dst=10.5.6.135
udp src=10.5.6.150      dst=10.5.6.1        dport=53  src=10.5.6.1        dst=10.5.6.150
udp src=10.5.6.169      dst=1.1.1.1         dport=53  src=10.5.6.1        dst=10.5.6.169
udp src=127.0.0.1       dst=127.0.1.1       dport=53  src=127.0.1.1       dst=127.0.0.1
udp src=192.168.3.1     dst=104.47.38.8     dport=53  src=104.47.38.8     dst=10.8.1.8
udp src=192.168.3.1     dst=108.59.162.43   dport=53  src=108.59.162.43   dst=10.8.1.8
udp src=192.168.3.1     dst=13.107.24.2     dport=53  src=13.107.24.2     dst=10.8.1.8
udp src=192.168.3.1     dst=150.171.17.38   dport=53  src=150.171.17.38   dst=10.8.1.8
udp src=192.168.3.1     dst=192.52.178.30   dport=53  src=192.52.178.30   dst=10.8.1.8
udp src=192.168.3.1     dst=193.108.88.128  dport=53  src=193.108.88.128  dst=10.8.1.8
udp src=192.168.3.1     dst=2.22.230.130    dport=53  src=2.22.230.130    dst=10.8.1.8
udp src=192.168.3.1     dst=40.90.4.2       dport=53  src=40.90.4.2       dst=10.8.1.8
udp src=192.168.3.1     dst=84.53.139.129   dport=53  src=84.53.139.129   dst=10.8.1.8
udp src=192.168.3.1     dst=95.100.173.129  dport=53  src=95.100.173.129  dst=10.8.1.8
tcp src=x.x.x.x         dst=1.0.0.1         dport=853 src=1.0.0.1         dst=x.x.x.x
tcp src=x.x.x.x         dst=1.1.1.1         dport=853 src=1.1.1.1         dst=x.x.x.x

and instead of showing VPN as source (sender) and WAN as destination (recipient) it how has the newly added 192.168.3.1 as source and VPN as destination.

Next steps
see what happenings when I add IPv6 back (1) to the network (2) to unbound and then
look at replacing OpenVPN with WireGuard. @ZebMcKayhan do you have any suggestions on a provider that supports IPv6 - I am using NordVPN and AFAIK, they do not support WireGuard on a router (only on their clients) and anyhow for them IPv6 support is still 'coming soon' (same as 5 years ago).

 

[ZebMcKayhan]

@ZebMcKayhan do you have any suggestions on a provider that supports IPv6 - I am using NordVPN and AFAIK, they do not support WireGuard on a router (only on their clients) and anyhow for them IPv6 support is still 'coming soon' (same as 5 years ago).

Not really, Im using "Integrity" from the "5th of July foundation" but they don't accept having individuals as their customers for privacy reasons so you need to go through your internet provider (altough their speed, uptime and services are really excellent).
https://5july.org/vpn/

NordVPN is possible to get working with the router:
https://www.snbforums.com/threads/session-manager-discussion-2nd-thread.75129/post-727552

@chongnt probably has more information about the details of extracting the .conf file.

The author of wgm (@Martineau) are using Mullvad which appears to be offering dual stack wireguard. Can't comment on their services though.
https://mullvad.net/en/

There are probably many others.

//Zeb

PS. If you didn't notice, there are several sections in my tutorial showing examples in how to setup Wireguard / wgm with IPv6. However, despite my efforts I have not manage to figure out any proper way for policy routing with IPv6 (except for entire subnets) as router is not really in control over self-assigned IPs. Any suggestions are very welcome.

 

[ringlord]

If it was up to me, I would make this one a sticky thread.
Unless we have an option to bookmark threads?
But I don't think that this option is enabled.

 

[Yota]

I know there is no consensus on the detection of DNS leaks online, but just to share some of how it works:

Yes, it uses Javascript, but I don't think it's "tricckery".

It uses JavaScript to let the browser resolve a random third-level domain belonging to the website, such as xxyyzz.example.org and then the DNS provider's server first passes the request to .org which is the top-level domain , and then to the website .example.org, because the first and the second domain may be cached by the DNS provider's server so that may no actual DNS request reaches these domains, this is the role of the random third-level domain xxyyzz, and the DNS server will eventually send xxyyzz.example.org query request to example.org, and then example.org records the request source server IP.

This is how the online DNS leak test basically works, but it's very inaccurate because the DNS provider may have a proxy, say 8.8.8.8 as the DNS server,but 8.8.8.8 only receives user's DNS request and never sends, instead the Google DNS server closest to the user. therefore, online DNS leak sites will provide the whois of the DNS query IP, and even the geographic location.

 

[RMerlin]

The only fully accurate way to detect "DNS leaks" is to monitor port 53 traffic on your router using tcpdump.

 

[Caesar the Dictator]

This thread, especially this website, it includes really useful and tutorial information for me. Thank you to every user.

Obviously, if the "DNS Privacy Protocol" option is active, I would have thought that all LAN devices have to use the DoT server. So I wouldn't think it would be any DNS leak (TCP/UDP 53, plain text). Because in the "Internet Status", it is clearly written "DNS (Overridden by DNS Privacy)". Therefore, I thought that "Connect to DNS server automatically, Yes or No" options are insignificant.

As a result, *any* of those DNS servers is just as likely as another to be used. What you need to do is configure "Connect to DNS server automatically" as No, but leave the custom servers blank! When you do, now you'll find that only Stubby (127.0.1.1) is available to the router.

I have only one question. When I set the Custom Servers blank and click "Apply" I see the following warning. It stands like it is impossible to leave blank. How can we do that?

#Please set up the DNS server on the client device.

 

[ColinTaylor]

Obviously, if the "DNS Privacy Protocol" option is active, I would have thought that all LAN devices have to use the DoT server. So I wouldn't think it would be any DNS leak (TCP/UDP 53, plain text).

No. Just because you've configured your router to run a DoT server doesn't mean the clients are forced to use it. It's down to the client as to what DNS server/protocol they use. IoT devices for example typically have their DNS server address hard-coded to something like 8.8.8.8. That's one of the reasons this script exists, to detect that sort of behaviour. The DNSFilter is a way to try and force clients to use a specific server.

 

[Caesar the Dictator]

@ColinTaylor I know clients can use the preset DNS protocol and DNS server. I'm sorry if I couldn't express myself properly. I wanted to emphasize the issue I quoted in my post above. That is, I expect all LAN devices to just use the configured DoT server (eg 1.1.1.1:853). However, legacy DNS protocol (for example 1.1.1.1:53) can be used because we cannot leave some places blank in the router GUI. I hope my thinking is just a misunderstanding.

 

[ColinTaylor]

I have only one question. When I set the Custom Servers blank and click "Apply" I see the following warning. It stands like it is impossible to leave blank. How can we do that?

There is some strange logic which generates that message. It will only appear if both fields are empty and your "WAN Connection Type" is not "Automatic IP" (e.g. it's PPPoE).

 

[eibgrad]

Obviously, if the "DNS Privacy Protocol" option is active, I would have thought that all LAN devices have to use the DoT server. So I wouldn't think it would be any DNS leak (TCP/UDP 53, plain text). Because in the "Internet Status", it is clearly written "DNS (Overridden by DNS Privacy)". Therefore, I thought that "Connect to DNS server automatically, Yes or No" options are insignificant.

All WLAN/LAN devices *do* use the DoT server exclusively (at least for those using DHCP and that accept the router as their local DNS proxy). That's NOT the issue.

What the dnsmon script shows is that the router itself, for its own DNS purposes (WAN connectivity check, accessing the time servers for NTP, etc.), does NOT use DoT exclusively. It will use ALL available DNS servers, DoT plus any configured on the WAN via DHCP or custom servers, w/ no particular favoritism shown to any one of them. And as I've stated many, many times, whether that qualifies as a DNS leak is up to YOU. Different users will feel differently depending on their particular circumstances.

Some users will argue it doesn't matter since they don't consider the router a participant in the masking of their DNS queries. They're only concerned w/ the WLAN/LAN clients, since they're the ones using applications. But that kind of reasoning starts to get a bit "fuzzy" when you consider the router is often used as an applications platform itself (e.g., someone decides to install Deluge, Transmission, etc., from Entware), and now the router becomes a potential source of DNS leaks just like any WLAN/LAN client.

In short, the script exposes what's actually happening w/ respect to what DNS servers are being used, and via which network interfaces, regardless whether it's the WLAN/LAN clients or the router itself. But ultimately YOU have to decide if any of those plaintext DNS queries over the WAN represent a problem.

 

[iTyPsIDg]

Some users will argue it doesn't matter since they don't consider the router a participant in the masking of their DNS queries. They're only concerned w/ the WLAN/LAN clients, since they're the ones using applications. But that kind of reasoning starts to get a bit "fuzzy" when you consider the router is often used as an applications platform itself (e.g., someone decides to install Deluge, Transmission, etc., from Entware), and now the router becomes a potential source of DNS leaks just like any WLAN/LAN client.

In addition to this, it also gets a bit "fuzzy" when you consider streaming services. It seems they perform some sort of check that uses the router's DNS location to determine your geographic location.

 

[Caesar the Dictator]

There is some strange logic which generates that message. It will only appear if both fields are empty and your "WAN Connection Type" is not "Automatic IP" (e.g. it's PPPoE).

Thanks for finding the source of that message for me.

All WLAN/LAN devices *do* use the DoT server exclusively (at least for those using DHCP and that accept the router as their local DNS proxy). That's NOT the issue.

What the dnsmon script shows is that the router itself, for its own DNS purposes (WAN connectivity check, accessing the time servers for NTP, etc.), does NOT use DoT exclusively. It will use ALL available DNS servers, DoT plus any configured on the WAN via DHCP or custom servers, w/ no particular favoritism shown to any one of them. And as I've stated many, many times, whether that qualifies as a DNS leak is up to YOU. Different users will feel differently depending on their particular circumstances.

Some users will argue it doesn't matter since they don't consider the router a participant in the masking of their DNS queries. They're only concerned w/ the WLAN/LAN clients, since they're the ones using applications. But that kind of reasoning starts to get a bit "fuzzy" when you consider the router is often used as an applications platform itself (e.g., someone decides to install Deluge, Transmission, etc., from Entware), and now the router becomes a potential source of DNS leaks just like any WLAN/LAN client.

In short, the script exposes what's actually happening w/ respect to what DNS servers are being used, and via which network interfaces, regardless whether it's the WLAN/LAN clients or the router itself. But ultimately YOU have to decide if any of those plaintext DNS queries over the WAN represent a problem.

Thanks for helping me to understand the issue better.

 

[learning_curve]

Question... Is it possible... to force ALL DNS queries to be routed via DNS-overTLS (DOT) - IF - Your ISP connection is PPPoE AND your ISP's Modem is in Bridge mode to your Asus router AND you use IPv6 & IPv4?
I'm thinking probably not, but quite often on this forum, somebody points out "the obvious" that you've missed!

I feel very positive (thanks to OP @eibgrad providing a very useful way to check everything for IPv4 DNS) that I have no DNS Leaks currently, although in fairness, as has been clearly stated in post #1 of this thread, it's not possible to use this script for IPv6 - yet, so I can't be 100% sure at this point in time. Unless... I switch IPv6 off completely, which I don't want to do, as I regularly use IPv6 as it has quite a few different uses (in my case).

The fact that my ISP connection is PPPoE (there is no other available option) means that when using WAN -> Connect to DNS Server automatically -> No this PPPoE selection, removes the possibility of leaving both of the DNS Servers 1 & 2 with blank entries ( as detailed in this post HERE by @ColinTaylor ) so in my case, I've used Cloudfare servers, because if change it to WAN -> Connect to DNS Server automatically -> Yes then by default & in /tmp/resolv.conf etc I have my ISP's DNS Servers which of course, I don't want. Here's my relevant setup bits:

• LAN -> DNS Server 1 -> Blank
• LAN -> DNS Server 2 -> Blank
• LAN -> Advertise router's IP in addition to user-specified DNS -> No
• WAN -> Connect to DNS Server automatically -> No
• WAN -> DNS Server 1 -> 1.1.1.1
• WAN -> DNS Server 2 -> 1.0.0.1
• WAN -> Forward local domain queries to upstream DNS -> No
• WAN -> Enable DNS Rebind protection -> Yes
• WAN -> Enable DNSSEC support -> Yes
• WAN -> Validate unsigned DNSSEC replies -> Yes
• WAN -> Prevent client auto DoH -> Yes
• WAN -> DNS Privacy Protocol -> DNS-over-TLS(DOT)
• WAN -> DNS-over-TLS Profile Strict -> Strict
• WAN -> DNS-over-TLS Server List (1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001)
• DNS Filter -> Enabled -> Global Filter Mode -> Router
• Administration - System -> Network Monitoring -> DNS Query
• Administration - System -> Resolve Hostname -> localhost
• Administration - System -> Resolved IP Addresses -> 127.0.0.1

A few of those ^ settings, were applied only after reading this thread, but they all appear to work perfectly so far.
Things like cat /etc/resolv.conf - cat /tmp/resolv.conf - cat /rom/etc/resolv.conf & cat /tmp/resolv.dnsmasq all produced the expected data and results. The attached recent screngrab image (the dupe values being indicative of just that moment in time. they are not consistent, obviously) and the DNS-over-TLS Server List does intentionally include Cloudfare IPV6 servers as well as IPv4 servers - because as stated, I do use IPv6.

Back to the original question and... is it possible? Or is it a case of "No you've no DNS leaks anyway. Move on!"

NB Not directly connected, but just in case, having read another helpful post HERE which I've also followed and also works perfectly (for me / my setup anyway), the WAN DDNS is still fully functional afterwards, but with those additional local usage benefits (not via Enable WEB access from WAN, which is set to NO, as is the case for most)

What I noticed (not that it matters, because this should happen) is that when using say, the dig command from a device on the LAN, it means that in IPv4 dig myname.ddns.net @1.1.1.1 +dnssec +multi refers back to 192.168.1.1 and in IPv6 dig AAAA myname.ddns.net @2606:4700:4700::1111 +dnssec +multino records can be found. If these and/or any other dig or similar commands are run on another network instead of on my own LAN, or, external DNS checks e.g. https://dnschecker.org are run from on either, they do run & produce the correct results, as expected.

 

[eibgrad]

Question... Is it possible... to force ALL DNS queries to be routed via DNS-overTLS (DOT) - IF - Your ISP connection is PPPoE AND your ISP's Modem is in Bridge mode to your Asus router AND you use IPv6 & IPv4?
I'm thinking probably not, but quite often on this forum, somebody points out "the obvious" that you've missed!

I feel very positive (thanks to OP @eibgrad providing a very useful way to check everything for IPv4 DNS) that I have no DNS Leaks currently, although in fairness, as has been clearly stated in post #1 of this thread, it's not possible to use this script for IPv6 - yet, so I can't be 100% sure at this point in time. Unless... I switch IPv6 off completely, which I don't want to do, as I regularly use IPv6 as it has quite a few different uses (in my case).

The fact that my ISP connection is PPPoE (there is no other available option) means that when using WAN -> Connect to DNS Server automatically -> No this PPPoE selection, removes the possibility of leaving both of the DNS Servers 1 & 2 with blank entries ( as detailed in this post HERE by @ColinTaylor ) so in my case, I've used Cloudfare servers, because if change it to WAN -> Connect to DNS Server automatically -> Yes then by default & in /tmp/resolv.conf etc I have my ISP's DNS Servers which of course, I don't want. Here's my relevant setup bits:

A few of those ^ settings, were applied only after reading this thread, but they all appear to work perfectly so far.
Things like cat /etc/resolv.conf - cat /tmp/resolv.conf - cat /rom/etc/resolv.conf & cat /tmp/resolv.dnsmasq all produced the expected data and results. The attached recent screngrab image (the dupe values being indicative of just that moment in time. they are not consistent, obviously) and the DNS-over-TLS Server List does intentionally include Cloudfare IPV6 servers as well as IPv4 servers - because as stated, I do use IPv6.

Back to the original question and... is it possible? Or is it a case of "No you've no DNS leaks anyway. Move on!"

NB Not directly connected, but just in case, having read another helpful post HERE which I've also followed and also works perfectly (for me / my setup anyway), the WAN DDNS is still fully functional afterwards, but with those additional local usage benefits (not via Enable WEB access from WAN, which is set to NO, as is the case for most)

What I noticed (not that it matters, because this should happen) is that when using say, the dig command from a device on the LAN, it means that in IPv4 dig myname.ddns.net @1.1.1.1 +dnssec +multi refers back to 192.168.1.1 and in IPv6 dig AAAA myname.ddns.net @2606:4700:4700::1111 +dnssec +multino records can be found. If these and/or any other dig or similar commands are run on another network instead of on my own LAN, or, external DNS checks e.g. https://dnschecker.org are run from on either, they do run & produce the correct results, as expected.

View attachment 40353

The fact you have WAN DNS showing as 127.0.0.1 suggests to me you also have Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" set to Yes (something you didn't mention).

As mentioned previously, enabling this settings forces the router itself to use DNSMasq. And DNSMasq is normally configured with whatever is defined under "Connect to DNS Server automatically". But there's an exception. If you enable DoT on the WAN, "Connect to DNS Server automatically" becomes irrelevant. It's ignored as far as DNSMasq is concerned. DNS is updated to point to Stubby (127.0.1.1) and only use the configured DoT servers.

So without having any detailed information about IPv6 connections available via the script, if we assume IPv6 is working correctly w/ Stubby (DoT), I see no reason for concern, whether it's IPv4 or IPv6. At least to the extent you can guarantee all your DNS is directed through DNSMasq (use of the DNS filter helps to make sure that's the case).

 

[Caesar the Dictator]

...The DNSFilter is a way to try and force clients to use a specific server.

I have one last question. Does DNSFilter prevent clients from using servers in Do53 protocol only? I see in Diversion logs Apple devices connecting to domains containing the word "doh".

 

[eibgrad]

I have one last question. Does DNSFilter prevent clients from using servers in only Do53 protocol only? I see in Diversion logs Apple devices connecting to domains containing the word "doh".

DNS filtering is strictly limited to Do53. You can clearly see this by dumping the NAT table, where the DNSFILTER chain is only a target of the client when using tcp or udp over port 53.

admin@RT-AC68U-0960:/tmp/home/root# iptables -t nat -vnL PREROUTING
Chain PREROUTING (policy ACCEPT 352 packets, 59670 bytes)
 pkts bytes target     prot opt in     out     source               destination         
...
    0     0 DNSFILTER  udp  --  br+    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 DNSFILTER  tcp  --  br+    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53

The reason this is the case is because anything else is likely to be secured by TLS, and you can't redirect such a request to somewhere else. That's the whole point of using something other than Do53 in the first place; so your DNS can't be hijacked or redirected!

 

[learning_curve]

The fact you have WAN DNS showing as 127.0.0.1 suggests to me you also have Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" set to Yes (something you didn't mention).

That's correct. Again, chosen by me after reading earlier posts in this excellent thread, detailing this option, why it now exists and its effects etc. Sorry, I'm not sure why I forgot to include that bit of information in the initial post.

As mentioned previously, enabling this settings forces the router itself to use DNSMasq. And DNSMasq is normally configured with whatever is defined under "Connect to DNS Server automatically".

Yes, I'd understood this ^^ part...

But there's an exception. If you enable DoT on the WAN, "Connect to DNS Server automatically" becomes irrelevant. It's ignored as far as DNSMasq is concerned. DNS is updated to point to Stubby (127.0.1.1) and only use the configured DoT servers.

But I hadn't realised this ^^ part Brilliant!

So without having any detailed information about IPv6 connections available via the script, if we assume IPv6 is working correctly w/ Stubby (DoT), I see no reason for concern, whether it's IPv4 or IPv6. At least to the extent you can guarantee all your DNS is directed through DNSMasq (use of the DNS filter helps to make sure that's the case).

Great! That's pretty much answered the question now then. Thanks again for your involvement and this thread.

 

[JAX1337]

Finally, it took some real effort to turn those reds to yellow and green,
with pihole, unbound and stubby.

Nice project, this needs more attention.