Tutorial How to monitor DNS traffic in real-time

[SomeWhereOverTheRainBow]

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. It seems to work.

mount -o bind /rom/etc/resolv.conf /tmp/resolv.conf

That's a cool technique, I do something similar.

 

[chongnt]

That's a cool technique, I do something similar.

I learn this from @Martineau. It was used to tag ip route table number to a friendly name for wireguard.
In this context, I can revert the change with umount /tmp/resolv.conf, then bind mount again. This changes works seamlessly without the need to restart any services.

Wireguard - Session Manager - Discussion (2nd) thread

Hey! Does the output from diag cmd gets saved as a file? not that I'm aware of. you will have to capure it from the terminal window... still not working eah? //Zeb

www.snbforums.com

 

[octopus]

Thank you!

I have just configure as your script and a have all "green" and I can resolve inside lan, tested with one of my vpnclient.
I'm using my vpn providers DNS to my IP-provider.
My vpn bypass working fine too.

 

[TonyK132]

Please comment on this screen shot of running dns-monitor. It's a lot of red but I suspect all the accesses are for unbound which means it is probably OK but I'm not sure. Do I need to worry about these DNS leaks? All the blanked out addresses are my WAN address.

 

[eibgrad]

Please comment on this screen shot of running dns-monitor. It's a lot of red but I suspect all the accesses are for unbound which means it is probably OK but I'm not sure. Do I need to worry about these DNS leaks? All the blanked out addresses are my WAN address.

It's NOT easy to interpret the output w/ so little context. Providing the header would tell me the router's LAN ip, VPN status, etc. Is unbound running on the router or some other LAN device? And if it's the latter, what is its IP? And how is unbound configured wrt DNS servers? I see a LOT of red indicating potential DNS leaks since those are all presumably Do53 (in the clear) traffic over the WAN. What's odd is the quantity. For all those in RED, the first dst field represent a different DNS server. That's a LOT of DNS servers! Most ppl might have 2 or 3 at most.

 

[ColinTaylor]

Please comment on this screen shot of running dns-monitor. It's a lot of red but I suspect all the accesses are for unbound which means it is probably OK but I'm not sure. Do I need to worry about these DNS leaks? All the blanked out addresses are my WAN address.

I did a quick reverse lookup on some of the more obvious IP addresses and they were TLD DNS servers so it probably is Unbound traffic.

 

[SomeWhereOverTheRainBow]

It's NOT easy to interpret the output w/ so little context. Providing the header would tell me the router's LAN ip, VPN status, etc. Is unbound running on the router or some other LAN device? And if it's the latter, what is its IP? And how is unbound configured wrt DNS servers? I see a LOT of red indicating potential DNS leaks since those are all presumably Do53 (in the clear) traffic over the WAN. What's odd is the quantity. For all those in RED, the first dst field represent a different DNS server. That's a LOT of DNS servers! Most ppl might have 2 or 3 at most.

Sounds like they are running in recursive mode server.

 

[SomeWhereOverTheRainBow]

Sounds like they are running in recursive mode server.

Unbound manager has a mode where the recursive lookups can be pushed through the VPN tunnel, and the dns lookups will appear the same as the vpn provider. For reference, the way to turn it on can be found on their forum threads. Also, the user will have to disable ipv6 dns using this method or otherwise it may prove to be another source of dnsleak since the vpn servers don't route ipv6 traffic.

 

[jsbeddow]

Sounds like they are running in recursive mode server.

Yes, I just ran these tests yesterday, and came to essentially the same conclusions: I run Unbound in recursive DNS server mode, and my results would fluctuate wildly between green, yellow and (mostly) red, regardless of any tweaks to various settings as discussed in this thread. I think this was discussed in the early days of implementing Unbound on our Asus routers: the tradeoff for having many "in the clear" DNS responses was the fact that they are more spread out across many, many DNS servers around the world, rather than being consolidated all at one chosen (or ISP chosen) DNS server.

As is the case with many of the mods we do to our routers, there are choices and tradeoffs involved.

 

[SomeWhereOverTheRainBow]

I think this was discussed in the early days of implementing Unbound on our Asus routers: the tradeoff for having many "in the clear" DNS responses was the fact that they are more spread out across many, many DNS servers around the world, rather than being consolidated all at one chosen (or ISP chosen) DNS server.

One of the problems with running unbound recursive server on a client such as a pihole comes when dealing with limited available ports behind the nat, while the traffic experienced by the client goes out port 53, unbound makes many outbound connections to its multiple servers around the world using port randomization , without limiting the outbound port avoid/permit, it can be hard for devices needing a port to be available to make a connection if it is trying to use the same one used by unbound. One solution is to limit the outgoing port avoid/permit.But by restricting these ports used you cripple some of the port randomization.

 

[eibgrad]

Yes, I just ran these tests yesterday, and came to essentially the same conclusions: I run Unbound in recursive DNS server mode, and my results would fluctuate wildly between green, yellow and (mostly) red, regardless of any tweaks to various settings as discussed in this thread. I think this was discussed in the early days of implementing Unbound on our Asus routers: the tradeoff for having many "in the clear" DNS responses was the fact that they are more spread out across many, many DNS servers around the world, rather than being consolidated all at one chosen (or ISP chosen) DNS server.

As is the case with many of the mods we do to our routers, there are choices and tradeoffs involved.

Even without the recursive server configuration, the OP is going to have DNS leaks. At least if the OP considers this an issue (as I say all the time, YOU have to decide; not everyone agrees). Assuming they do, the question is what to do about it.

If unbound was on a WLAN/LAN device, he could configure DoT on the WAN and automatically have all that traffic routed through the DoT server. But being on the router, the router itself does NOT use the DoT server, at least NOT by default. You'd have to force the router to participate by setting Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" to Yes.

At that point, all the RED should disappear.

There are other options as well, such as using an OpenVPN client. But at least DoT costs you nothing.

P.S. Not sure what the performance implications might be, esp. if recursive mode is maintained.

 

[SomeWhereOverTheRainBow]

Even without the recursive server configuration, the OP is going to have DNS leaks. At least if the OP considers this an issue (as I say all the time, YOU have to decide; not everyone agrees). Assuming they do, the question is what to do about it.

If unbound was on a WLAN/LAN device, he could configure DoT on the WAN and automatically have all that traffic all routed through the DoT server. But being on the router, the router itself does NOT use the DoT server, at least NOT by default. You'd have to force the router to participate by setting Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" to Yes.

At that point, all the RED should disappear.

There are other options as well, such as using an OpenVPN client. But at least DoT costs you nothing.

Well, with DoT you can't get a refund or recover some form of loss, or hold someone responsible for your security. Honestly though it is arguable that both offer a false sense of security. In reality, one only truly benefits if they are experiencing a geolocation crisis or government censorship like in some countries around the world.

 

[eibgrad]

Well, with DoT you can't get a refund or recover some form of loss, or hold someone responsible for your security. Honestly though it is arguable that both offer a false sense of security. In reality, one only truly benefits if they are experiencing a geolocation crisis like in some countries around the world.

Fair point. But of course I'm only offering technical solutions, while NOT commenting on their efficacy. I'll leave that to the OP.

 

[SomeWhereOverTheRainBow]

Fair point. But of course I'm only offering technical solutions, while NOT commenting on their efficacy. I'll leave that to the OP.

I completely agree, I hope you continue to share with your experience, and I will continue to share joint user experience. I think it is best to collaborate and better understand. What do you think about the newer encryptions such as DoQ or ODoH? Or even anonymized dnscrypt?

 

[TonyK132]

Please comment on this screen shot of running dns-monitor. It's a lot of red but I suspect all the accesses are for unbound which means it is probably OK but I'm not sure. Do I need to worry about these DNS leaks? All the blanked out addresses are my WAN address.

Thanks to all for your comments. My unbound is running on the router not on another device, not going thru a VPN tunnel, and configured to not use DoT as recommended by the unbound guys. I'm also relived to see that others with a similar config are also seeing lots of red, so I'll consider this to be normal for this config. One reason for all the red entries might be that I'm also banning access to/from a bunch of countries (ru, ur, *stans, cn, others) using Skynet, so unbound might be searching for valid authoritative DNS to get data from.

 

[eibgrad]

I completely agree, I hope you continue to share with your experience, and I will continue to share joint user experience. I think it is best to collaborate and better understand. What do you think about the newer encryptions such as DoQ or ODoH? Or even anonymized dnscrypt?

As far as anonymization, seems to me separation of the resolver from the end user via a proxy is inevitable. But once the traffic leaves your own network, it's always the same question; who do you trust? What's to stop the proxy and resolver from colluding? And how would you know? And it just makes things that much more complicated (as if DNS wasn't complicated enough already).

As far as DoQ, I read a brief synopsis and it went right over my head. Seems to be a means to more efficiency than added privacy/security, but it's not like I spent much time on it.

 

[SomeWhereOverTheRainBow]

As far as anonymization, seems to me separation of the resolver from the end user via a proxy is inevitable. But once the traffic leaves your own network, it's always the same question; who do you trust? What's to stop the proxy and resolver from colluding? And how would you know? And it just makes things that much more complicated (as if DNS wasn't complicated enough already).

As far as DoQ, I read a brief synopsis and it went right over my head. Seems to be a means to more efficiency than added privacy/security, but it's not like I spent much time on it.

I think there is one problem with all these services. Provided the domain they are reaching out to for encryption some how gets blocked either via ISP or DNS, then most the time users are forced to fall back to port 53. All encryption traffic requires an initial connection, without such, the traffic is effectively blocked. The same with IP addresses and ports, if it somehow becomes blocked, there goes your effective dns scheme. Same goes for VPN providers as well.

 

[jsbeddow]

If unbound was on a WLAN/LAN device, he could configure DoT on the WAN and automatically have all that traffic routed through the DoT server. But being on the router, the router itself does NOT use the DoT server, at least NOT by default. You'd have to force the router to participate by setting Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" to Yes.

At that point, all the RED should disappear.

There are other options as well, such as using an OpenVPN client. But at least DoT costs you nothing.

P.S. Not sure what the performance implications might be, esp. if recursive mode is maintained.

Hmm...not sure how one could achieve this "have all that traffic routed through the DoT server" (emphasis on "the" server, singular), when using Unbound on the router as a recursive DNS solution that reaches out to many DNS servers. Maybe if using Unbound simply as a substitute for dnsmasq and Stubby, where one can define one or two DNS servers.

I have tried all the presented solutions here, including removing the GUI interface DNS servers, as well as setting this "Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" to Yes" followed by a reboot, to observe behavior after the reboot. I had brief periods where it appeared to be settling into all "green" status, but that didn't last long, and was immediately followed by lengthy sections of mostly "red" DNS inquiries. Not sure what else could be done, but it seems out of reach to get fully encrypted responses in all cases when Unbound is setup as a recursive DNS server on the router.

 

[eibgrad]

Hmm...not sure how one could achieve this "have all that traffic routed through the DoT server" (emphasis on "the" server, singular), when using Unbound on the router as a recursive DNS solution that reaches out to many DNS servers. Maybe if using Unbound simply as a substitute for dnsmasq and Stubby, where one can define one or two DNS servers.

I have tried all the presented solutions here, including removing the GUI interface DNS servers, as well as setting this "Tools > Other Settings > "Wan: Use local caching DNS server as system resolver (default: No)" to Yes" followed by a reboot, to observe behavior after the reboot. I had brief periods where it appeared to be settling into all "green" status, but that didn't last long, and was immediately followed by lengthy sections of mostly "red" DNS inquiries. Not sure what else could be done, but it seems out of reach to get fully encrypted responses in all cases when Unbound is setup as a recursive DNS server on the router.

You're right. I spoke too soon there. DoT would only be an option for those bound to DNSMasq, NOT some other local DNS server. Not unless you somehow had Unbound being directed through DNSMasq. Otherwise, you'd have to use a VPN if you wanted to prevent the DNS leaks over the WAN.

 

[gattaca]

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 leaking DNS for it's own functional purposes or the DNS of the clients or both?