Tutorial How to monitor DNS traffic in real-time

[SomeWhereOverTheRainBow]

I have unbound and route it over vpn. It used to be all green. But few days ago I noticed a lot of red entry with my WAN as source. The recipient dst side still show my vpn ip though. Any idea what could possibly cause this?
View attachment 47830

the router himself traffic?

are you routing the routers "own" local traffic thru the vpn? if not, then you will see its own dns traffic traveling via wan. Any clients not travelling VIA way of VPN will also use unbound through WAN typically, unless you define port 53 traffic from those clients to specifically traverse the VPN. This has one caveat, the rules would have to be defined before any other rules for those clients to ensure that specific traffic hits the vpn.

 

[chongnt]

the router himself traffic?

are you routing the routers "own" local traffic thru the vpn? if not, then you will see its own dns traffic traveling via wan. Any clients not travelling VIA way of VPN will also use unbound through WAN typically, unless you define port 53 traffic from those clients to specifically traverse the VPN. This has one caveat, the rules would have to be defined before any other rules for those clients to ensure that specific traffic hits the vpn.

It seems to happen about the same time when I start browsing from my connected devices.
When I set VPN to redirect all traffic through tunnel to yes, then everything is back to green. Source are now 10.7.0.2 instead of WAN IP.

 

[SomeWhereOverTheRainBow]

It seems to happen about the same time when I start browsing from my connected devices.
When I set VPN to redirect all traffic through tunnel to yes, then everything is back to green. Source are now 10.7.0.2 instead of WAN IP.

View attachment 47839

To me, it sounds like conflict resides in the rule order possibly. Some clients must be hitting wan instead of the proper rule.

 

[iTyPsIDg]

It seems to happen about the same time when I start browsing from my connected devices.
When I set VPN to redirect all traffic through tunnel to yes, then everything is back to green. Source are now 10.7.0.2 instead of WAN IP.

View attachment 47839

You have to be careful with this. I ran into the issue last year and got into an infinite reboot loop that required a factory reset to resolve. The short of it is that if you use the killswitch and force traffic over the VPN, you run into a problem because the router needs DNS before establishing a VPN connection.

https://www.snbforums.com/threads/use-vpn-exclusive-dns-and-local-dns.77246/post-751573 and https://www.snbforums.com/threads/unable-to-log-into-router-ax86u-after-reboot.77831/

 

[chongnt]

To me, it sounds like conflict resides in the rule order possibly. Some clients must be hitting wan instead of the proper rule.

Finally find the reason, somehow I comment out the outgoing-interface in unbound, end up my WAN IP is use as source. Now the source is my router local ip.

< outgoing-interface: 192.168.1.1        # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)
---
> #outgoing-interface: 192.168.1.1        # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)

 

[chongnt]

Noticed something cosmetic. DoT is correctly show in yellow when routed over WAN. After I route it over VPN, it still show in yellow.
Have not seen @eibgrad for a while. Hope everything is well. It seems DNS over QUIC is not covered. Perhaps can include this in the next update.

 

[whatsup]

hi all am i doing something wrong in my settings asus merlin firmware 386.9 asus RT-AC86u.
sorry just trying out the addon . Nubbie.

 

[chongnt]

hi all am i doing something wrong in my settings asus merlin firmware 386.9 asus RT-AC86u.
sorry just trying out the addon . Nubbie.

Hi, do you mean the grep error message? You can refer to the last page of this thread for fix.

 

[whatsup]

Hi, do you mean the grep error message? You can refer to the last page of this thread for fix.

yes that's correct. everything seems to be working fine. but not sure regarding the above. is it a conflict or have i the wrong router settings. using cloudflare

 

[whatsup]

Hi, do you mean the grep error message? You can refer to the last page of this thread for fix.

can you point me in the right direction. thanking you

 

[chongnt]

can you point me in the right direction. thanking you

either way will get rid of the grep warning message
option 1. fix the path

Tutorial - How to monitor DNS traffic in real-time

... since the last batch of Entware updates a week or so ago I'm now getting lots of warning messages about egrep/grep when I run this script now? I just noticed this yesterday. It happens when we use entware /opt/bin/egrep. If we use /bin/egrep there is no such error. .... Quick fix is to...

www.snbforums.com

or option 2. edit the script

Tutorial - How to monitor DNS traffic in real-time

handy tool to keep in the bookmark list.. https://dnscheck.tools/

www.snbforums.com

 

[archiel]

Maybe its just me but.... Following this thread I had emptied out the default WAN servers (I am using Cloudflare for Strict DoT) and only route some traffic (including client DNS requests via unbound) through a Wireguard VPN. Without this blanking the WAN servers, there is always some residual red (plain txt over port 53) traffic. What I had missed until this weekend (and doing a factory reset - rebuild) is that Skynet cannot update its files unless there are also non-encrypted DNS servers. As this was not throwing up an error message in syslog the result is that for the best part of a of year my filter list had not been updated!

AFAIK all other default process and scripts worked as expected (with default WAN servers blanked out). So it seems to me (and I could be wrong) that

If ALL traffic is going though a VPN then using some default WAN servers would not be an issue as these will only be used until the VPN is up.
If only some traffic is being routed though the VPN and you want to use Skynet, you must set some default unencrypted DNS servers (at least until someone tweaks Skynet, so that the filter lists can be successfully downloaded otherwise).

 

[Viktor Jaep]

Maybe its just me but.... Following this thread I had emptied out the default WAN servers (I am using Cloudflare for Strict DoT) and only route some traffic (including client DNS requests via unbound) through a Wireguard VPN. Without this blanking the WAN servers, there is always some residual red (plain txt over port 53) traffic. What I had missed until this weekend (and doing a factory reset - rebuild) is that Skynet cannot update its files unless there are also non-encrypted DNS servers. As this was not throwing up an error message in syslog the result is that for the best part of a of year my filter list had not been updated!

AFAIK all other default process and scripts worked as expected (with default WAN servers blanked out). So it seems to me (and I could be wrong) that

If ALL traffic is going though a VPN then using some default WAN servers would not be an issue as these will only be used until the VPN is up.
If only some traffic is being routed though the VPN and you want to use Skynet, you must set some default unencrypted DNS servers (at least until someone tweaks Skynet, so that the filter lists can be successfully downloaded otherwise).

It's highly recommended to have WAN DNS servers populated because there are some housekeeping items that need to happen before your router becomes functional after a reboot, like getting time from time servers, etc. Theoretically, you would think it would be possible to keep them blank, and hope that all necessary traffic can make it out through the VPN, but it's not always the case. Once your router comes up and the vpn connection is established, you can basically force this scenario with some VPN director rules.

 

[archiel]

It's highly recommended to have WAN DNS servers populated because there are some housekeeping items that need to happen before your router becomes functional after a reboot, like getting time from time servers, etc. Theoretically, you would think it would be possible to keep them blank, and hope that all necessary traffic can make it out through the VPN, but it's not always the case. Once your router comes up and the vpn connection is established, you can basically force this scenario with some VPN director rules.

I follow in theory, but in practice everything other than Skynet appears to load correctly with the default WAN DNS servers blank. Certainly time is set without any issue via the DoT WAN DNS servers and well before either unbound or wireguard are loaded.

 

[ColinTaylor]

Certainly time is set without any issue via the DoT WAN DNS servers...

That's because the router's DoT falls back to using non-encrypted DNS when the router's time hasn't been set. So this leads people to think that everything is encrypted when it actually isn't. Personally I don't understand this obsession people have with trying to fix theorical "leaks" with DNS for a few seconds when the router boots up. It's not like the FSB/NSA are actually interested in them or which NTP server they're using.

 

[archiel]

That's because the router's DoT falls back to using non-encrypted DNS when the router's time hasn't been set. So this leads people to think that everything is encrypted when it actually isn't. Personally I don't understand this obsession people have with trying to fix theorical "leaks" with DNS for a few seconds when the router boots up. It's not like the FSB/NSA are actually interested in them or which NTP server they're using.

Not the point I was trying to make. If there are entries in the default WAN DNS, then some WAN queries will go out this way. Whether these are important or significant is something completely different. The point was simply that following the techniques in this thread to remove all plain txt DNS queries once the route is up and running, will mean that Skynet will not update its filter lists. If intelligence agencies want to track mine or your activities then no home router (and in practice no commercial routers, firewalls, etc.) are going to be anything more than an minor annoyance.

 

[ColinTaylor]

The point was simply that following the techniques in this thread to remove all plain txt DNS queries once the route is up and running, will mean that Skynet will not update its filter lists.

Is this an issue specifically with Skynet, or does it apply to other services running on the router? Perhaps you have Tools - Other Settings > Wan: Use local caching DNS server as system resolver set to No (the default).

 

[learning_curve]

Is this an issue specifically with Skynet, or does it apply to other services running on the router? Perhaps you have Tools - Other Settings > Wan: Use local caching DNS server as system resolver set to No (the default).

Good point well made. I have Tools - Other Settings >Wan: Use local caching DNS server as system resolver set to YES intentionally, by choice, as part of this policy, plus relevant to this specific case; I don't use Skynet at all. I haven't had any problems (albeit I have a fairly simple setup) with DNS at all, since I adopted this monitoring.

 

[archiel]

Is this an issue specifically with Skynet, or does it apply to other services running on the router? Perhaps you have Tools - Other Settings > Wan: Use local caching DNS server as system resolver set to No (the default).

The issue appears to just be with Skynet. I do have Tools - Other Settings > Wan: Use local caching DNS server as system resolver set to No, as I am using unbound.

 

[ColinTaylor]

The issue appears to just be with Skynet. I do have Tools - Other Settings > Wan: Use local caching DNS server as system resolver set to No, as I am using unbound.

I don't know anything about how Unbound works but by setting that Tools option to No you're telling the router's onboard services to go directly to the WAN DNS servers. So what you're seeing is expected behaviour as far as I understand your description.

Personally, I always have this option set as Yes otherwise the router cannot resolve local host names. Yes used to be the default setting until Merlin changed it a few releases back.