Tutorial How to monitor DNS traffic in real-time

[eibgrad]

I don't see the point in setting dns automatic to no and clearing leaving it blank, when setting use local cache as system resolver on the tools page to yes replaces the dns with 127.0.0.1 and 127.0.1.1 which is effectively doing the same thing .

I'm NOT arguing against it. I wasn't even aware of the other option. So I haven't even evaluated it. I'm merely reporting what worked for me. If you or others have better options, I'm all ears. I don't claim to know the *best* solution(s). I'm more interested in making the problems KNOWN, then letting you guys decide what works best.

 

[SomeWhereOverTheRainBow]

I'm NOT arguing against it. I wasn't even aware of the other option. So I haven't even evaluated it. I'm merely reporting what worked for me. If you or others have better options, I'm all ears. I don't claim to know the *best* solution(s). I'm more interested in making the problems KNOWN, then letting you guys decide what works best.

No I was asking for educational purposes. If you get a chance to investigate I am interested. By putting 127.0.0.1 inside /etc/resolv.conf, you shouldn't be required to solely rely on /etc/host for client names from my understanding, that should be the only real difference. Everything else would be identical.

 

[eibgrad]

UPDATE: Version 1.2.0 is now available.

Just as before, don't expect any change in the results. So far (knock wood), I haven't found any errors in the data collection or my interpretation of it. As before, what's changed is mostly cosmetic (external UI and internal code), and hopefully some minor additional efficiencies.

I did add a monochrome option [m] that will use BOLD, ITALIC, and NORMAL font attributes in place of the default RED, YELLOW, and GREEN color attributes, per the request of @ringlord.

I also exposed the [d] option in the menu (which was hidden until now) for including the dupe-count in the connection information.

I don't know what future enhancements would be worth the effort at this point. I don't anticipate any of my own until WireGuard support is added, at which point it will obviously have its own effects on DNS, similar to OpenVPN. I guess we'll cross that bridge when we get to it.

 

[chongnt]

I tried to change tools wan use local caching dns. Indeed /etc/resolv.conf shows 127.0.0.1. But as expected I have problem that NTP cannot sync after reboot. I have revert the settings and now /etc/resolv.conf correctly show my configured dns. Not sure what else I did. Now nvram get wan_ipaddr shows 0.0.0.0 instead of my WAN ip. Nvram get wan0_ipaddr is able to show my WAN ip correctly. Any idea how to fix nvram get wan_ipaddr to show WAN ip again?

Update: Seems like this is the behavior. wan_ipaddr only refreshed after access the WAN GUI page; whereas wan0_ipaddr automatically update itself.
@eibgrad , perhaps can consider update WAN IP with wan0_ipaddr instead of wan_ipaddr?

Getting WAN IP in a script

I used to use Tomato firmware, and I have scripts that use the WAN IP. I could get it like this: #!/bin/sh WANIP=$(nvram get wan_ipaddr) echo $WANIP Now I've updated my router (an Asus RT-N66U) to use Asuswrt-Merlin firmware, and I guess it doesn't work the same way, since the above code...

www.snbforums.com

 

[eibgrad]

No I was asking for educational purposes. If you get a chance to investigate I am interested. By putting 127.0.0.1 inside /etc/resolv.conf, you shouldn't be required to solely rely on /etc/host for client names from my understanding, that should be the only real difference. Everything else would be identical.

I took a closer look today. And btw, thanks for pointing this option out. As I said, I didn't even realize it was there. That's why I depend on you guys to tell me when I might have missed something, and hopefully increase the utility's accuracy.

For all intents and purposes, this option does what DD-WRT does by default; turn the WAN's DNS usage into a local reference (i.e., DNSMasq).

From monitoring the connections, I can see that /etc/resolv.conf has changed to using only 127.0.0.1, but /tmp/resolv.conf remains the same, and the script assumes the latter is always current. So I'll probably have to update the script to use /etc/resolv.conf for displaying the proper WAN DNS. Frankly, I find it disturbing that yet again another part of the system messes w/ DNS to create this inconsistency. I *thought* I could depend on /tmp/resolv.conf.

The one difference I could find between using tools option vs. leaving the custom DNS servers on the WAN blank is that the former resulted in a double loopback reference, first to 127.0.0.1 (DNSMasq), then to 127.0.1.1 (Stubby), rather than the later just creating a direct reference to 127.0.1.1 (Stubby). Not that it matters all that much being entirely local.

OTOH, using a reference to DNSMasq (127.0.0.1) does offer the advantage of local name resolution to the router itself without having to rely solely on //etc//hosts. IOW, if you prefer to add DNS records to DNSMasq using either the address or host-record directives, these will now be available to the router (and of course the WLAN/LAN clients).

So clearly either way will work.

One thing seems certain. It makes no sense to have DoT enabled and to NOT use either blank custom DNS servers or the tools option, since doing so creates a DNS leak. NOT unless the user is clearly aware that's what's going to happen and they just don't care. But at least the utility exposes what's happening and raises the question. Each user will have to decide for themselves whether it matters and what to do about it.

P.S. You do have to wonder why that tool option isn't on the WAN configuration page, rather than buried in the Tools menu. Seems odd. And even perhaps why it isn't enabled by default as well.

 

[SomeWhereOverTheRainBow]

I took a closer look today. And btw, thanks for pointing this option out. As I said, I didn't even realize it was there. That's why I depend on you guys to tell me when I might have missed something, and hopefully increase the utility's accuracy.

For all intents and purposes, this option does what DD-WRT does by default; turn the WAN's DNS usage into a local reference (i.e., DNSMasq).

From monitoring the connections, I can see that /etc/resolv.conf has changed to using only 127.0.0.1, but /tmp/resolv.conf remains the same, and the script assumes the latter is always current. So I'll probably have to update the script to use /etc/resolv.conf for displaying the proper WAN DNS. Frankly, I find it disturbing that yet again another part of the system messes w/ DNS to create this inconsistency. I *thought* I could depend on /tmp/resolv.conf.

The one difference I could find between using tools option vs. leaving the custom DNS servers on the WAN blank is that the former resulted in a double loopback reference, first to 127.0.0.1 (DNSMasq), then to 127.0.1.1 (Stubby), rather than the later just creating a direct reference to 127.0.1.1 (Stubby). Not that it matters all that much being entirely local.

OTOH, using a reference to DNSMasq (127.0.0.1) does offer the advantage of local name resolution to the router itself without having to rely solely on //etc//hosts. IOW, if you prefer to add DNS records to DNSMasq using either the address or host-record directives, these will now be available to the router (and of course the WLAN/LAN clients).

So clearly either way will work.

One thing seems certain. It makes no sense to have DoT enabled and to NOT use either blank custom DNS servers or the tools option, since doing so creates a DNS leak. NOT unless the user is clearly aware that's what's going to happen and they just don't care. But at least the utility exposes what's happening and raises the question. Each user will have to decide for themselves whether it matters and what to do about it.

P.S. You do have to wonder why that tool option isn't on the WAN configuration page, rather than buried in the Tools menu. Seems odd. And even perhaps why it isn't enabled by default as well.

I think the responses will benefit from DNSMASQ 127.0.0.1 cache before requesting from stubby though. That is the main benefit I could see, Also the dnsmasq local resolution.

 

[SomeWhereOverTheRainBow]

P.S. You do have to wonder why that tool option isn't on the WAN configuration page, rather than buried in the Tools menu. Seems odd. And even perhaps why it isn't enabled by default as well.

If it were my configuration, I would just disable port 53 on dnsmasq, and set stubby to respond to all request at port 53, Obviously you would have to add an option to dnsmasq so dnsmasq knows to hand out the DHCP address that it is no longer providing the DNS for though.

 

[ColinTaylor]

P.S. You do have to wonder why that tool option isn't on the WAN configuration page, rather than buried in the Tools menu. Seems odd. And even perhaps why it isn't enabled by default as well.

This is historical. In Asus' firmware on-router name resolution goes directly to the WAN DNS servers rather than dnsmasq. In the past Merlin's firmware used dnsmasq for on-router name resolution (much more sensible IMHO). Then in 384.12 RMerlin changed the default behaviour to be the same as Asus' while giving the user the option to choose which method they prefer.

384.12 (22-June-2019)
:
  - CHANGED: The router will now use ISP-provided resolvers
             instead of local dnsmasq when attempting to
             resolve addresses, for improved reliability.
             This reproduces how stock firmware behaves.
             This only affects name resolution done
             by the router itself, not by the LAN clients.
             The behaviour can still be changed on the
             Tools -> Other Settings page.

 

[jsbeddow]

This is historical. In Asus' firmware on-router name resolution goes directly to the WAN DNS servers rather than dnsmasq. In the past Merlin's firmware used dnsmasq for on-router name resolution (much more sensible IMHO). Then in 384.12 RMerlin changed the default behaviour to be the same as Asus' while giving the user the option to choose which method they prefer.

384.12 (22-June-2019)
:
  - CHANGED: The router will now use ISP-provided resolvers
             instead of local dnsmasq when attempting to
             resolve addresses, for improved reliability.
             This reproduces how stock firmware behaves.
             This only affects name resolution done
             by the router itself, not by the LAN clients.
             The behaviour can still be changed on the
             Tools -> Other Settings page.

I remember this changover, but have never understood how this change was done "for improved reliability". Anyone care to comment on pros and cons here?

 

[eibgrad]

This is historical. In Asus' firmware on-router name resolution goes directly to the WAN DNS servers rather than dnsmasq. In the past Merlin's firmware used dnsmasq for on-router name resolution (much more sensible IMHO). Then in 384.12 RMerlin changed the default behaviour to be the same as Asus' while giving the user the option to choose which method they prefer.

384.12 (22-June-2019)
:
  - CHANGED: The router will now use ISP-provided resolvers
             instead of local dnsmasq when attempting to
             resolve addresses, for improved reliability.
             This reproduces how stock firmware behaves.
             This only affects name resolution done
             by the router itself, not by the LAN clients.
             The behaviour can still be changed on the
             Tools -> Other Settings page.

Ah, I now have a vague memory of this, long before I had any understanding of how DNS was handled on Merlin, so it didn't have much impact at the time.

As you can see though, the default behavior derives no benefits from DNSMasq. And enabling DoT on the WAN provides no benefit to the router itself either. I'd bet dollars to donuts the vast majority of users *assume* that if they enable DoT on the *WAN*, the router is going to use DoT.

 

[ColinTaylor]

Ah, I now have a vague memory of this, long before I had any understanding of how DNS was handled on Merlin, so it never had much impact at the time.

As you can see though, the default behavior derives no benefits from DNSMasq. And enabling DoT on the WAN provides no benefit to the router itself either. I'd bet dollars to donuts the vast majority of users *assume* that if they enable DoT on the *WAN*, the router is going to use DoT.

I think this goes back to a time when users were frequently f@ucking up their dnsmasq config, and playing around with experimental versions of DoT, NTP client, etc. As such it was common to see people complaining about things like "my DNS don't work" when it was actually caused by their router not being able to set it's time correctly.

 

[eibgrad]

I remember this changover, but have never understood how this change was done "for improved reliability". Anyone care to comment on pros and cons here?

This is why I hesitate sometimes to simply endorse an option like this in Tools. Who knows why anyone would NOT have the router use DNSMasq by default, esp. when I've seen it done this way w/ DD-WRT, with no known particular bad effects (at least NOT known to me). But you don't always know the total rationale behind some changes.

EDIT: Just saw CT's recent post.

 

[SomeWhereOverTheRainBow]

I remember this changover, but have never understood how this change was done "for improved reliability". Anyone care to comment on pros and cons here?

The issue revolved around users in certain DNS environments (double nat for instance.) not being able to set the clock time in time to start dot dns-i.e. the chicken and the egg. Along with this issue, a slue of user base scripts that relied on the clock to set ultimately would not run, all the way to vpn servers not reliably starting. There was alot going on under the hood that was breaking because of the delimma , too much fruitless endeavors wasted chasing the problem. When the simple solution is , why are we concerned with how the router himself resolves local traffic. If there are no client leaks, then there is no real delimma. (That was the thought process; not saying it is my thought process.)

 

[eibgrad]

When the simple solution is , why are we concerned with how the router himself resolves local traffic. If there are no client leaks, then there is no real delimma. (That was the thought process; not saying it is my thought process.)

Once again we get back to what's the definition of a DNS leak. I've seen numerous users who expected their router-hosted applications (e.g., transmission) to be routed over the VPN, only to find out once they enabled routing policy, that wasn't the case. It was routed over the WAN, DNS et al.

You can clearly see this mindset when you see the following in routing policy.

192.168.1.0/24 <blank> OVPN1

I'm sure most users *think* this binds the router itself (e.g., 192.168.1.1) to the VPN. It does in the sense that any internet traffic that's initiated from its LAN interface will use the VPN, but the router doesn't typically use the LAN interface for such purposes (the GUI being a rare exception) since it's hosting the internet connections (WAN and VPN) and can (unlike the WLAN/LAN clients) access them directly!

You sometimes see the following as well, only emphasizing the point.

192.168.1.1 <blank> WAN
192.168.1.0/24 <blank> OVPN1

Of course, the first rule is pointless. Once routing policy is in effect, the router is no longer bound to the VPN anyway. The rule is benign, but it shows what the user (wrongly) believes about how the routing is configured wrt the VPNs.

I only bring this up to illustrate that these same beliefs apply to DNS. I doubt most users see the router as distinct from the WLAN/LAN clients, at least in terms of security/privacy. And while those changes from long ago may correct those particular problems, it comes w/ consequences which are likely incompatible w/ their current assumptions.

But I understand why things like this are done sometimes. And that they have their own rationale. But the reason I wrote the script is to expose this behavior so at least it can be questioned. And at least for those that care, they can take appropriate countermeasures.

Truth is, there is no "one size fits all" answer. DNS is a world of compromises. For every good argument to do things one way, there are equally good arguments to do it another way.

As I said in my original post, you can't even get agreement on what exactly is a DNS leak. And why I find the typical online third-party tools so worthless.

P.S. I just uploaded a minor update to v1.2.1 which now looks at /etc/resolv.conf for determining the WAN's DNS servers. So it will now properly reflect any change to that DNS server option in the Tools menu.

 

[SomeWhereOverTheRainBow]

Once again we get back to what's the definition of a DNS leak. I've seen numerous users who expected their router-hosted applications (e.g., transmission) to be routed over the VPN, only to find out once they enabled routing policy, that wasn't the case. It was routed over the WAN, DNS et al.

You can clearly see this mindset when you see the following in routing policy.

192.168.1.0/24 <blank> OVPN1

I'm sure most users *think* this binds the router itself (e.g., 192.168.1.1) to the VPN. It does in the sense that any internet traffic that's initiated from its LAN interface will use the VPN, but the router doesn't typically use the LAN interface for such purposes (the GUI being a rare exception) since it's hosting the internet connections (WAN and VPN) and can (unlike the WLAN/LAN clients) access them directly!

You sometimes see the following as well, only emphasizing the point.

192.168.1.1 <blank> WAN
192.168.1.0/24 <blank> OVPN1

Of course, the first rule is pointless. Once routing policy is in effect, the router is no longer bound to the VPN anyway. The rule is benign, but it shows what the user (wrongly) believes about how the routing is configured wrt the VPNs.

I only bring this up to illustrate that these same beliefs apply to DNS. I doubt most users see the router as distinct from the WLAN/LAN clients, at least in terms of security/privacy. And while those changes from long ago may correct those particular problems, it comes w/ consequences which are likely incompatible w/ their current assumptions.

But I understand why things like this are done sometimes. And that they have their own rationale. But the reason I wrote the script is to expose this behavior so at least it can be questioned. And at least for those that care, they can take appropriate countermeasures.

Truth is, there is no "one size fits all" answer. DNS is a world of compromises. For every good argument to do things one way, there are equally good arguments to do it another way.

As I said in my original post, you can't even get agreement on what exactly is a DNS leak. And why I find the typical online third-party tools so worthless.

P.S. I just uploaded a minor update to v1.2.1 which now looks at /etc/resolv.conf for determining the WAN's DNS servers. So it will now properly reflect any change to that DNS server option in the Tools menu.

I get what you are saying, but when it comes to starting the VPN. If it becomes too much of a problem to get the vpn running at what point do you consider the router to be an actual router, versus a client. With no distinction, then who does the routing? the modem? In that case lets put this baby in bridge mode.

 

[eibgrad]

I get what you are saying, but when it comes to starting the VPN. If it becomes too much of a problem to get the vpn running at what point do you consider the router to be an actual router, versus a client. With no distinction, then who does the routing? the modem? In that case lets put this baby in bridge mode.

Seems to me that question was answered long ago. These routers have always been applications platforms. Look at all the crap running on them. It could be argued that even DNS and the VPNs more properly belong OFF the router. I fully agree that ideally the router should *only* be a router, NOT a client. But that's just isn't the case. As I indicated w/ my example of transmission, users expect applications to be running on the router for a variety of purposes. Of course, biasing your config for the benefit of those applications may compromise its overall stability (including getting the WAN connected), but that's always been part of the equation when it comes to third-party firmware.

Anyway, seems to me that's where the tension lies. Whether the router is or isn't a proper "client". Where you fall on either side of that wall will probably determine how you see the issue of DNS leaks, and what is the proper configuration for the router. And I can see the argument for both sides.

And btw, ASUS has recently up'd the ante. Starting w/ 386.4, they've now decided to statically bind the WAN's DNS servers to the WAN. That's already causing additional problems.

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

The user had a legitimate need for local name resolution, thus the preference for Strict (which uses DNSMasq) over Exclusive (which doesn't). Forget about whether the router needs protection for *itself* against DNS leaks. As long as it's acting as an agent/proxy for the WLAN/LAN clients, it is, for all practical purposes, a client of both the DNS and VPN services since those same clients suffer from any of its shortcomings.

At least in this one case, it was solved. But it would certainly never be intuitive to the average user what was happening and how to overcome it.

 

[eibgrad]

BTW, if it isn't obvious already, I'm purposely stoking the fire here on this issue NOT to be argumentative just for its own sake, but so it can be flushed out as much as possible in this one thread, rather than the usual case of having bits and pieces of relevant information dispersed among countless other threads. For those w/ an interest in DNS, I think they would like to have as much information as possible in this one thread so they can make up their own minds about the issues.

 

[SomeWhereOverTheRainBow]

BTW, if it isn't obvious already, I'm purposely stoking the fire here on this issue NOT to be argumentative just for its own sake, but so it can be flushed out as much as possible in this one thread, rather than the usual case of having bits and pieces of relevant information dispersed among countless other threads. For those w/ an interest in DNS, I think they would like to have as much information as possible in this one thread so they can make up their own minds about the issues.

I think that is part of the "do not press the red button". You and I both know even if one is told not to press the red button, there is a good probability they will do it any ways whether it was necessary or not. BTW, I am referring to DNS, and VPN's and not the great information rich conversations we have had.

 

[chongnt]

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

 

[capncybo]

I think that is part of the "do not press the red button". You and I both know even if one is told not to press the red button, there is a good probability they will do it any ways whether it was necessary or not. BTW, I am referring to DNS, and VPN's and not the great information rich conversations we have had.

Ohhhhh... you mean this RED Button ??? (LOL)