Tutorial How to monitor DNS traffic in real-time

[Viktor Jaep]

This was EYE-OPENING, @eibgrad! Thank you so much for this script. This definitely helped me shore things up and tighten up my settings. Also, thanks for the hint on that "screen" function... I never even knew that was a possibility -- that right there is worth it's weight in gold!

 

[eibgrad]

That used to be the case but Asus made an upstream change which necessitated the new behaviour in 386.4.

I assume this is why they also decided to now (quietly) bind the WAN's DNS servers to the WAN (!), further complicating matters when it comes to DNS leaks.

For example, suppose you've configured the custom DNS servers on the WAN w/ 1.1.1.1 and 1.0.0.1, in the belief that once you have the OpenVPN client established and set to route ALL over the VPN, those DNS servers will now be routed over the VPN too. NOPE! Those are still bound to the WAN, and so now you have a DNS leak!

Basically, too many parts of the system are involved in managing DNS, making it extremely difficult to know what's actually happening. If you don't have a tool like this script available to you, how would you even know the above wasn't working as expected?

 

[eibgrad]

This was EYE-OPENING, @eibgrad! Thank you so much for this script. This definitely helped me shore things up and tighten up my settings. Also, thanks for the hint on that "screen" function... I never even knew that was a possibility -- that right there is worth it's weight in gold!

Yeah, screen can be very useful. I use it all the time for situations where I need something to keep running in the background, and occasionally need to visit it to check the most recent output, typically watchdog processes. But just about anything that's going to run continuously and produces meaningful output, or take a very long time to complete, is well suited for screen. Once you've found how helpful it is, you'll use it all the time. It's particularly well-suited for this script.

 

[archiel]

Apologies in advance for foolish questions, but this is currently way over my head. I am using unbound for DNS and also have ipv6 enabled, native with DHCP-PD

I only use VPNs for a couple of connections and the VPN is set to exclusive so I would expect to see a lot of red for the rest of the traffic, however i see mostly green and all of it is IPv6 (and the devices using the VPN tunnel have IPv6 disabled). Looking at the IPv6 queries they are mostly going to/from the WAN ipv6 address - also I do not see this address in the WAN/LAN IP/: header.

All the DNS queries I can see are over udp, in your example you also have tcp - is this a result of using unbound?

Sometimes on a page refresh I can see a whole list of green IPv4 queries, some LAN clients to router and some LAN clients to VPN tunnel. I then see a whole batch of red WAN to external lookups - is there a way to know whether any of these relate to the VPN rather than the queries that should be going out via the WAN?

 

[eibgrad]

Apologies in advance for foolish questions, but this is currently way over my head. I am using unbound for DNS and also have ipv6 enabled, native with DHCP-PD

I only use VPNs for a couple of connections and the VPN is set to exclusive so I would expect to see a lot of red for the rest of the traffic, however i see mostly green and all of it is IPv6 (and the devices using the VPN tunnel have IPv6 disabled). Looking at the IPv6 queries they are mostly going to/from the WAN ipv6 address - also I do not see this address in the WAN/LAN IP/: header.

All the DNS queries I can see are over udp, in your example you also have tcp - is this a result of using unbound?

Sometimes on a page refresh I can see a whole list of green IPv4 queries, some LAN clients to router and some LAN clients to VPN tunnel. I then see a whole batch of red WAN to external lookups - is there a way to know whether any of these relate to the VPN rather than the queries that should be going out via the WAN?

I should have probably mentioned; the script *assumes* IPv4. And I have no access to IPv6 at the moment in order to support it. So in all likelihood, what the script is reporting is NOT meaningful. I would have to update the script for IPv6 support in the future.

 

[eibgrad]

UPDATE: Version 1.1.0 available.

Added a few new features, but nothing that will change the results. Mostly cosmetic cleanup and menu options for the UI. I had intended to add them all along, but wanted to get the core functionality out to the forum without getting bogged down by these other issues.

1. You can now temporarily enable/disable the WAN check from the menu. If it's still disabled at the point of exit, it will automatically be restored to enabled.

2. You can hide/show the header from the menu. Hiding it provides more room for the display of the most important data; the connections themselves.

3. You can increase/decrease the update frequency from a minimum of 3 to a maximum of 30 seconds from the menu. Anything beyond 30 risks missing some connection data, particularly UDP.

4. You can enable/disable logging from the menu. If there's no data in the log at the time of exit, it will NOT report the log file. It will simply delete the empty file.

5. You can pause the display and update process as needed from the menu.

6. There's now a formal exit option in the menu that handles various housekeeping requirements, although Ctrl-C will accomplish the exact same thing.

Again, don't expect different results.

P.S. There's a hidden 'd' (dupes) option on the menu that will display the number of duplicates for a given record. I did NOT make it part of the formal menu since it really adds nothing meaningful to the results. It's more of a curiosity to see just how active your system really is. Most ppl will be quite surprised. And this is only monitoring DNS, to speak nothing of the traffic that follows in response.

 

[ugandy]

thanks! any changes to the install instructions?

 

[eibgrad]

thanks! any changes to the install instructions?

Nope. Exactly the same.

 

[octopus]

When you download from Pastebin you get file with double .sh ( merlin-dns-monitoring.sh.sh) on download button.

Thank you for your script.

 

[eibgrad]

When you download from Pastebin you get file with double .sh ( merlin-dns-monitoring.sh.sh) on download button.

Thank you for your script.

PasteBin is barely adequate and not all that smart. I always name my scripts w/ the .sh extension on their system. And since it's identified to their system specifically as a Bash file (that's why it uses the proper color coding), it automatically adds .sh to the file as part of the download, *even* if the file name already ends in .sh! What can I say. It's dumb. Ever use its ZIP download feature? All the contained files have the '-' removed (presumably because they need it to separate the file name from their unique identifier), so if you had to use the ZIP file to reconstruct your files, you'd have to do so MANUALLY!

Honestly, how dumb is that.

 

[octopus]

PasteBin is barely adequate and not all that smart. I always name my scripts w/ the .sh extension on their system. And since it's identified to their system specifically as a Bash file (that's why it uses the proper color coding), it automatically adds .sh to the file as part of the download, *even* if the file name already ends in .sh! What can I say. It's dumb. Ever use its ZIP download feature? All the contained files have the '-' removed (presumably because they need it to separate the file name from their unique identifier), so if you had to use the ZIP file to reconstruct your files, you'd have to do so MANUALLY!

View attachment 39241

Honestly, how dumb is that.

Ok thanks.
Just want to tell those who not get your script working with double .sh extension

 

[HardCat]

This is such a fantastic little utility, thank yo so much for this!

 

[Chuckles67]

+1 this is great, thank you!

For my setup, all lines are green or yellow (DNS over TLS to Cloudflare), except one red line that looks like this, and has several duplicates:
udp src=<WAN-IP> dst=<WAN-DNSServer1-IP> dport=53 src=<WAN-DNSServer1-IP> dst=<WAN-IP>

Reading this thread, I think this one red line is router traffic to the DNS server - perhaps keep alive, or pinging. I did try routing all traffic to the <WAN-DNS1Server1-IP> through a VPN connection, but the red line continued to be appear. I'm not so worried about this, as I'm think the LAN client DNS traffic is encrypted with DoT. Still bit curious.

Thank you again!

 

[ZebMcKayhan]

+1 this is great, thank you!

For my setup, all lines are green or yellow (DNS over TLS to Cloudflare), except one red line that looks like this, and has several duplicates:
udp src=<WAN-IP> dst=<WAN-DNSServer1-IP> dport=53 src=<WAN-DNSServer1-IP> dst=<WAN-IP>

Reading this thread, I think this one red line is router traffic to the DNS server - perhaps keep alive, or pinging. I did try routing all traffic to the <WAN-DNS1Server1-IP> through a VPN connection, but the red line continued to be appear. I'm not so worried about this, as I'm think the LAN client DNS traffic is encrypted with DoT. Still bit curious.

Thank you again!

The script disables the router dns lookup for wan connection tracking on startup but the connection tracking keeps the connection for acouple of minutes. For me it takes 3-4 minutes for the red line to dissappear. Have you tried to wait that long with the script running? It enables it again on exit so you need to run it for some time.

If you have a lot of custom scripts running they could occasionally do dns lookup when they execute their cron tasks so it could be tricky to tell.

 

[eibgrad]

The script disables the router dns lookup for wan connection tracking on startup ...

It actually does NOT disable the dns lookup on startup. YOU have to use the [w] menu option to toggle the wan connectivity check between disable/enable.

 

[ZebMcKayhan]

It actually does NOT disable the dns lookup on startup. YOU have to use the [w] menu option to toggle the wan connectivity check between disable/enable.

Really? When I run the script it started up with wan check disabled... funny...

Edit: just raned it again and it started up enabled... figures... so yeah, check and set the setting appropriately.

 

[Chuckles67]

I pressed w and waited, and the red line disappeared: all else are yellow and green. Nice.

 

[chongnt]

I pressed w and waited, and the red line disappeared: all else are yellow and green. Nice.

From command egrep 'dport=(53|853) ' /proc/net/nf_conntrack in the first post, the 5th column of the output is "aging timer" of that tracked entry. This egrep 'dport=(53|853) ' /proc/net/nf_conntrack | grep $(nvram get wan_ipaddr) | awk '{print $5}' | sort -rn | head -1 will just show WAN IP entry with the highest "aging timer". I use this to see how long to wait for the red line to disappear.

 

[LimJK]

Hi @eibgrad

May I know if the instructions in your 1st post, can be used for Stock Firmware environment or it only supports Merlin's Firmware.

 curl -kLs pastebin.com/raw/AGNF8cC8 | tr -d '\r' | sh

During your first release, the above works in my Stock Firmware environment (RT_AX88U_3.0.0.4_386_46065). However, I get "No Data" after your latest update. Did I missed some steps.

Thanks. I look forward to use your handy work to track DNS leakages

 

[eibgrad]

Hi @eibgrad

May I know if the instructions in your 1st post, can be used for Stock Firmware environment or it only supports Merlin's Firmware.

 curl -kLs pastebin.com/raw/AGNF8cC8 | tr -d '\r' | sh

During your first release, the above works in my Stock Firmware environment (RT_AX88U_3.0.0.4_386_46065). However, I get "No Data" after your latest update. Did I missed some steps.

Thanks. I look forward to use your handy work to track DNS leakages

Given this is the Asuswrt-Merlin forum, it wasn't my intention to support the OEM/stock firmware. Not that I would mind if it did, of course. But I don't even have access to it. And reviewing the code right now, I don't see an obvious reason why if worked previously, it wouldn't work now.

One of the differences in the latest release is that it will actually report <no-data> after the column headings when there is literally no DNS activity. The initial release reported nothing (which was really a bug), which I thought might lead some users to think it wasn't working. Is that the No Data you're referring to, or something else?