Tutorial How to monitor DNS traffic in real-time

[eibgrad]

Been following this thread. I recall many questions about leaving DNS Server 1/DNS Server 2 blank was answered moons ago. @RMerlin 's guidance was: "do not leave'm blank or NTP and other time dependent services (VPNs, ...) cannot start properly." What did I miss? We are concerned that the router is leading DNS for it's own functional purposes or the DNS of the clients or both?

View attachment 39415

As usual, it gets complicated.

The point you missed is that we were talking about leaving them blank in a specific context, namely, when DoT is enabled on the WAN. When that happens, the WAN's DNS servers are updated to include Stubby (127.0.1.1). IOW, if you had 1.1.1.1 and 1.0.0.1 before DoT was enabled, either because of being set automatically or custom servers, it would now be 1.1.1.1, 1.0.0.1, 127.0.1.1 on the WAN. And that means that *any* of those DNS servers are equally available to the WAN for name resolution. But only 127.0.1.1 provides DNS leak protection.

The idea behind leaving the custom servers blank is to force the router to *always* use 127.0.1.1 (Stubby), since it now becomes the only option available. It's NOT to eliminate any and all DNS servers on the WAN, which would be the case if you did NOT use DoT.

Then @SomeWhereOverTheRainBow pointed out that this wasn't necessary if you set Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" to Yes, which started a whole other discussion.

Apparently at one time the WAN *was* configured by default to use DNSMasq (127.0.0.1). And if that was the case today, we wouldn't even be having this discussion. The router would be using Stubby exclusively, just like the WLAN/LAN clients. But that was changed quite some time ago to make sure the router always had valid DNS servers available on the WAN, since users were messing w/ it trying to implement their own DoT, long before it was a built-in feature. And then that Tools option was made available so users could go back to the old way of configuring the WAN if they explicitly chose to do so.

So @SomeWhereOverTheRainBow's recommendation ended up being the preferred means to ensure that the router only uses Stubby, since DNSMasq provides other benefits as well (local name resolution, caching, etc.).

So no matter which method you choose, blank custom servers or that Tools option, the WAN now only has a local reference, either directly to Stubby itself (127.0.1.1), OR, indirectly through DNSMasq (127.0.0.1), respectively. Take your pick.

P.S. Here's the WAN configuration if you do nothing but enable DoT.

There are NO active WLAN/LAN clients at the time. Notice the DNS monitor is indicating that the DoT servers (127.0.1.1) are NOT being used. To the extent you believe this qualifies as a DNS leak (and that's certainly debatable), this is a problem.

 

[gattaca]

^^^ Got it. And since I use DNSFilter to bypass DOT for a few sensitive things like cameras, I will always see those green lines in your script for those being routed to QUAD9 or Cloudflare. I like to spread that love around.... so the router is not dependent on a SPOF "provider..." for critical things like 24/7 security cams. THANKS!

 

[octopus]

When added, disable DNS on client, config DNS on WAN page, added VPN-provider DNS to client VPN director and route on custom config.

Update software get wan connection to hang and can't reach webinterface and login.

Have to unplug wan cable and revert config to "orginal" and Accept DNS Configuration to "Exclusive"

I don't know why it's hangs?

 

[eibgrad]

When added, disable DNS on client, config DNS on WAN page, added VPN-provider DNS to client VPN director and route on custom config.

Update software get wan connection to hang and can't reach webinterface and login.

Have to unplug wan cable and revert config to "orginal" and Accept DNS Configuration to "Exclusive"

I don't know why it's hangs?

Are you trying to copy the instructions I provided to the OP in the following link?

Use VPN Exclusive DNS and Local DNS

I have a question related to https://www.snbforums.com/threads/local-dns-and-vpn-issue.55312/#post-468948, but thought I'd post a separate question since my setup is slightly different than what is described there. I have an Asus RC-AC86U router running Merlin v386.4. Its relevant...

www.snbforums.com

 

[octopus]

Are you trying to copy the instructions I provided to the OP in the following link?

Use VPN Exclusive DNS and Local DNS

I have a question related to https://www.snbforums.com/threads/local-dns-and-vpn-issue.55312/#post-468948, but thought I'd post a separate question since my setup is slightly different than what is described there. I have an Asus RC-AC86U router running Merlin v386.4. Its relevant...

www.snbforums.com

Yes

 

[eibgrad]

UPDATE: Version 1.3.0 is now available.

I decided to do one more update because of some minor display issues that I've noticed. As usual, there are no changes that will affect the results. All changes are related to the UI and management of the display.

1. I moved the menu to the top of the display. I found it a bit annoying to have it moving around as the number of data rows changed. It also keeps the focus on the data where it belongs. And helps to implement change #2 below.

2. By default, if you exceed the available vertical space needed to display the data, the script will now pause w/ the more command, thus preventing scrolling, and any further updates until you resolve it (e.g., hit space or enter until you reach the end, or hit R). If you prefer to NOT have this behavior but instead just have it automatically scroll to the end on each refresh, you can enable scrolling w/ menu option [ s ].

3. There's now an option to hide the wan/public ip [ i ] . I thought this might be useful for those who choose to upload a snapshot of the display, or even a video in some rare cases.

4. I changed how monochrome mode displays. I noticed that Windows + Putty was NOT capable of using italics (ugg). It works fine on Linux + Putty, but Windows has issues for some reason. Frankly, even bold on Windows isn't all that impressive; it seems to be more about increasing the brightness rather than increasing the font thickness. Anyway, I changed the italics to underline. Definitely NOT as nice in terms of the display aesthetics, but at least it works consistently across both Linux and Windows.

Enjoy!

 

[eibgrad]

UPDATE: Version 1.4.0 is now available.

@chongnt pointed out to me last night that how I was determining the WAN ip from nvram wasn't working for him when he had a dynamic IP and it changed after a reboot. It showed the old WAN ip. In the process of looking into the issue, I also noticed that the script was NOT working properly for dual WAN either.

So killing two birds w/ one stone, I decided to fix his problem and make the utility fully dual WAN compatible. All prior versions assumed a single WAN. But w/ this release, the script recognizes when dual mode is in effect and accurately reflects if and when DNS is being routed over either WAN, whether due to failover or for the purposes of load balancing.

When using the hide public IP feature, WAN1 is replaced w/ x.x.x.x, while WAN2 is replaced w/ y.y.y.y.

P.S. I'd be curious if perhaps dual WAN lead to any unexpected DNS leaks, esp. when you consider the likelihood that the OpenVPN clients are bound only to one of the WANs, and probably only the first in the case of load balancing. It might impact how you configure dual WAN, or whether you should use it at all!

 

[octopus]

Yes

Is this only way to get local hostnames working on lan?
https://www.snbforums.com/threads/use-vpn-exclusive-dns-and-local-dns.77246/post-742630

 

[eibgrad]

Is this only way to get local hostnames working on lan?
https://www.snbforums.com/threads/use-vpn-exclusive-dns-and-local-dns.77246/post-742630

Well you can use Disabled or Relaxed too. Like Strict, they all rely on DNSMasq, so local name resolution works. What Exclusive brings to the table is a GUARANTEE that for those bound to the VPN, their DNS will use the VPN as well. So if that's a requirement for you, then yes, Exclusive would be required.

One other possibility to consider is DoT. Since DoT is encrypted, it doesn't matter if it's routed over the WAN (or VPN). Not unless your requirements are so extreme as to NOT even allow it to be known to the ISP you're using it, or perhaps in some rare cases, finding the ISP is blocking port 853.

 

[Chuckles67]

Thanks @eibgrad - this looks very good.

 

[majnu]

Hi
I followed this thread to setup Cloudfare DNS. Diversion Setup Questions | SmallNetBuilder Forums (snbforums.com) and also just recently this thread which is how I stumbled across this program help cloudflare configuration | SmallNetBuilder Forums (snbforums.com)

Does this look okay? I'm guessing that by the strikeouts I've made that revealed my IP is that my DNS is not configured correctly.
Thanks

 

[eibgrad]

Hi
I followed this thread to setup Cloudfare DNS. Diversion Setup Questions | SmallNetBuilder Forums (snbforums.com) and also just recently this thread which is how I stumbled across this program help cloudflare configuration | SmallNetBuilder Forums (snbforums.com)

Does this look okay? I'm guessing that by the strikeouts I've made that revealed my IP is that my DNS is not configured correctly.
Thanks

On a side note, you can use the 'i' menu option of the script to hide your public IP.

The only problem is the one line in RED. The others that show your public IP are in YELLOW, indicating these are DNS queries made w/ DoT over the WAN, which I don't consider an issue, since those are encrypted.

The reason for the one RED line is fully explained (and how to correct it) in the following prior link of this thread.

Tutorial - How to monitor DNS traffic in real-time

Been following this thread. I recall many questions about leaving DNS Server 1/DNS Server 2 blank was answered moons ago. @RMerlin 's guidance was: "do not leave'm blank or NTP and other time dependent services (VPNs, ...) cannot start properly." What did I miss? We are concerned that the...

www.snbforums.com

 

[majnu]

On a side note, you can use the 'i' menu option of the script to hide your public IP.

The only problem is the one line in RED. The others that show your public IP are in YELLOW, indicating these are DNS queries made w/ DoT over the WAN, which I don't consider an issue, since those are encrypted.

The reason for the one RED line is fully explained (and how to correct it) in the following prior link of this thread.

Tutorial - How to monitor DNS traffic in real-time

Been following this thread. I recall many questions about leaving DNS Server 1/DNS Server 2 blank was answered moons ago. @RMerlin 's guidance was: "do not leave'm blank or NTP and other time dependent services (VPNs, ...) cannot start properly." What did I miss? We are concerned that the...

www.snbforums.com

if you set Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" to Yes

I have done the above and still get red lines

 

[eibgrad]

I have done the above and still get red lines

That image is too hard to read. You need to zoom in to the relevant data so I can read it. Might help too if you used mono mode too given the poor contrast w/ the red and background.

 

[majnu]

That image is too hard to read. You need to zoom in to the relevant data so I can read it. Might help too if you used mono mode too given the poor contrast w/ the red and background.

Sorry about the image quality, it should be legible now.
Edit - I removed ubound from amtm, reboot router and it looks good now

 

[eibgrad]

Sorry about the image quality, it should be legible now.

Seems likely you're doing the same as the the user in the following link, namely, using Unbound or something similar in recursive mode.

Tutorial - How to monitor DNS traffic in real-time

I noticed that /etc/resolv.conf symlink changed with the tools Wan: use local caching dns option. /etc/resolv.conf -> /tmp/resolv.conf /etc/resolv.conf -> /rom/etc/resolv.conf Since I have issues with ntp sync during startup, I added the following after NTP is ready. Not sure if this is ok...

www.snbforums.com

The user in that case decided this was OK since it's just a natural consequence of the DNS server they're using and how it's configured. For those who who want to avoid having this traffic routed over the WAN, the other option is to route it over a VPN.

 

[ugandy]

this script is super useful! many thanks to the author!

on my setup i see all my clients in green querying the router IP,
i also see all my unbound queries (channeled via VPN),
and i see a sole router query to 9.9.9.9

i think the router query is the wan heatbeat thingy from asus, so i'm leaving it alone.

as for the unbound via vpn (different subnet, not WAN) queries. could these be displayed in a separate color? :-D

thanks

 

[SomeWhereOverTheRainBow]

this script is super useful! many thanks to the author!

on my setup i see all my clients in green querying the router IP,
i also see all my unbound queries (channeled via VPN),
and i see a sole router query to 9.9.9.9

i think the router query is the wan heatbeat thingy from asus, so i'm leaving it alone.

as for the unbound via vpn (different subnet, not WAN) queries. could these be displayed in a separate color? :-D

thanks

I have to agree.

And @eibgrad has been the most helpful in its regard as well.

 

[eibgrad]

on my setup i see all my clients in green querying the router IP,
i also see all my unbound queries (channeled via VPN),
and i see a sole router query to 9.9.9.9

i think the router query is the wan heatbeat thingy from asus, so i'm leaving it alone.

That's why I provided the "disable wan check" option. This temporarily disable the WAN connectivity check. If that one query to 9.9.9.9 in RED then disappears after about 30 seconds, that's likely the cause.

as for the unbound via vpn (different subnet, not WAN) queries. could these be displayed in a separate color? :-D

The intent of the display is to differentiate those queries that use the WAN from those that do NOT, because of the former's implications when it come to DNS leaks. Among those queries that are NOT routed over the WAN, for whatever reasons (e.g., VPN), there are no obvious negative implications that require the kind of differentiation you're asking for. Again, given the intent of the script.

One of the reasons I provide the header information (including the VPNs) is so you can at least get an idea of *why* certain queries may be taking certain routes. Given how much DNS configuration is dispersed throughout the router, this can be very difficult at times. And the script helps to make things like this more obvious.

Frankly, I was thinking of adding DNS filters to the header as well for these very reasons.

So it's NOT that I don't understand why someone would find it useful to quickly and easily differentiate where queries are headed based on color-coding, but again, the purpose of the color-coding is only to alert the user to possible dangers (i.e., DNS leaks).

 

[ugandy]

That's why I provided the "disable wan check" option. This temporarily disable the WAN connectivity check. If that one query to 9.9.9.9 in RED then disappears after about 30 seconds, that's likely the cause.

thanks. with the disable wan check, the query to 9.9.9.9 goes away after a few minutes