dns.msftncsi.com flooding my NextDNS

[oli3]

I think it started with 386.4, from reading on here it seems to be the case as it's hardcoded now if empty so I can't get rid of it.

I tried some things people suggested from old posts to set dns_probe_content and dns_probe_host to null but that didn't stop the requests.

It's making like 15k resolves into NextDNS a day. I do have the paid plan but still this is quite silly. Any suggestions how to make it stop?

I am using NextDNS CLI installed on the router with cache enabled.

admin@RT-AX58U-6658:/tmp/home/root# nvram show | grep dns_probe
size: 69319 bytes (61753 left)
dns_probe=0
dns_probe_content=131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1
dns_probe_host=dns.msftncsi.com

 

[oli3]

Fixed it! Actually found something on a pi-hole forum that guided me.

Tools -> Other Settings -> Wan: Use local caching DNS server as system resolver (default: No) == Set to Yes and Apply

 

[glehel]

i wrote 0.0.0.0 in both places and the DNS request was terminated

 

[iJorgen]

Fixed it! Actually found something on a pi-hole forum that guided me.

Tools -> Other Settings -> Wan: Use local caching DNS server as system resolver (default: No) == Set to Yes and Apply

Does this setting do the same thing as "nextdns activate"command in the CLI?!
I use the "cache boost" setting in NextDNS to extend TTL values to 5 min in the local cache, so only seeing the router resolving "dns.msftncsi.com" every 5 minutes in the logs.

i wrote 0.0.0.0 in both places and the DNS request was terminated

Do you still see a correct WAN-led color, or is it "red"?

 

[DJones]

Pretty sure you can just firewall block dns.msftncsi.com and that should prevent any outgoing packets.

Though doing that your logs will be filled with firewall block logs.

 

[glehel]

Does this setting do the same thing as "nextdns activate"command in the CLI?!
I use the "cache boost" setting in NextDNS to extend TTL values to 5 min in the local cache, so only seeing the router resolving "dns.msftncsi.com" every 5 minutes in the logs.


Do you still see a correct WAN-led color, or is it "red"?

the WAN status is connected and does not change. ( Cable modem)

 

[oli3]

Does this setting do the same thing as "nextdns activate"command in the CLI?!
I use the "cache boost" setting in NextDNS to extend TTL values to 5 min in the local cache, so only seeing the router resolving "dns.msftncsi.com" every 5 minutes in the logs.


Do you still see a correct WAN-led color, or is it "red"?

Not sure if its the same as nextdns activate, i didn't run that. But with what i did in the gui I also see the request every 5 mins in nextdns. Much better than every 5 secs it was before.

 

[Wadadli]

Does anyone know if the dns_probe gets disabled if a router is set to AP mode ?
I would say yes but who knows.

 

[albinoman887]

just out of curiosity has anyone checked if dns_probe behaves the same way in stock as it does in merlin. I just find it strange and honestly kinda dumb that asus supposedly resorted to this hack as a wan detection scheme. I mean ive had plenty of router , they all had connection up/down indicators and they didn't have to query a dns constantly . I would check myself but its hard to find a window of time large enough to be able to mess with the router like that without feeling totally rushed cuz someone wants to do something that requires internet

 

[frequenzy]

Does anyone know if the dns_probe gets disabled if a router is set to AP mode ?
I would say yes but who knows.

It doesn’t get disabled. I have an ac68u running as AP mode and I see the requests on my adguardhome.

 

[SomeWhereOverTheRainBow]

I think it started with 386.4, from reading on here it seems to be the case as it's hardcoded now if empty so I can't get rid of it.

I tried some things people suggested from old posts to set dns_probe_content and dns_probe_host to null but that didn't stop the requests.

It's making like 15k resolves into NextDNS a day. I do have the paid plan but still this is quite silly. Any suggestions how to make it stop?

I am using NextDNS CLI installed on the router with cache enabled.

admin@RT-AX58U-6658:/tmp/home/root# nvram show | grep dns_probe
size: 69319 bytes (61753 left)
dns_probe=0
dns_probe_content=131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1
dns_probe_host=dns.msftncsi.com

I just travel over to

/jffs/configs/dnsmasq.conf.add

Where I add the line

server=/dns.msftncsi.com/1.1.1.1

All request for dns.msftncsi.com get forwarded to cloudflare

 

[SomeWhereOverTheRainBow]

It doesn’t get disabled. I have an ac68u running as AP mode and I see the requests on my adguardhome.

Correct, it doesn't because it is used by the router (and AP) to see if the internet is active. There are more elaborate ways to tell the internet is active though.

 

[spykos]

Since my ASUS is also also behind my provider's router I changed to below and no more requests to dns.msftncsi.com. LED is white too.

nvram set dns_probe_content=192.168.2.1
nvram set dns_probe_host=192.168.2.1

 

[dephekt]

I just travel over to

/jffs/configs/dnsmasq.conf.add

Where I add the line

server=/dns.msftncsi.com/1.1.1.1

All request for dns.msftncsi.com get forwarded to cloudflare

You don't need to do that. You can just set dns_probe_host to "one.one.one.one" and dns_probe_content to "1.1.1.1 1.0.0.1 2606:4700:4700::1001" to achieve the same results of using Cloudflare instead of Microsoft without having to resort to any sort of shenanigans that might cause issues down the road. You can do this via the web interface too.

What was changed was if you null out either field (or at least dns_probe_content) the firmware will silently restore the default values behind the scenes, outside of your visibility. You can change these values to other things, like dns_probe_host to "localhost" and dns_probe_content to "127.0.0.1" and it will effectively stop the probe requests from leaving the device without modifying your hosts file.

This seems to be asuswrt-merline behavior only, not behavior from upstream. I understand the motivation Merlin had behind this change was to reduce the support burden coming from people that nulled out the old values to stop the probes but then forgot about it and later come to the forums wondering why things like failover stopped working.

That said, I don't like this opaque, undocumented behavior where the values you configure are silently ignored for alleged harm reduction. If someone wants to stop the probes, the device should respect that and not have any further opinions on the matter. Part of using something like asuswrt-merlin is to have more control over the device. Having hidden behaviors that run counter to what the user expected to happen in an effort to save the user from themselves seems like an antipattern. Especially when it comes to unexpected traffic.

If we're insisting on keeping this behavior, what is happening should be readily apparent in the UI and nvram states. They should always reflect reality and not hide what the behavior will be.

As a user:

• if I disable the "DNS query" network monitoring I expect the device not to make DNS queries for the monitoring domain.
• if the network monitoring behavior can't be stopped, I expect the DNS query checkbox to not be modifiable.
• If the "resolve hostname" or "resolved IP adresses" fields cannot be empty, I expect an error message when saving the form and the default/previous values be restored in the UI.

 

[homenetworkyeet]

You've had a few answers here but here's what worked for me.
I tried nvram committing removing
dns_probe_content=
dns_probe_host=
dns_probe=0

The dns probes however, continued.

I tried the other methods people did of unticking boxes and doing random stuff.

If you want to truly eliminate the DNS requests from leaving the router, do the following:

nano /jffs/scripts/hosts.postconf

#!/bin/sh
CONFIG=$1
. /usr/sbin/helper.sh
pc_insert "127.0.0.1 localhost.localdomain localhost" "131.107.255.255 dns.msftncsi.com" $CONFIG

save, and reboot.

This will add it to the hosts file which will be checked before an outbound dns request.
The only downside is as others say, you can't use dns based down-detection any longer, which means Dual WAN will be affected.
And your router will always say it is connected to the internet.

 

[dephekt]

You've had a few answers here but here's what worked for me.
I tried nvram committing removing
dns_probe_content=
dns_probe_host=
dns_probe=0

The dns probes however, continued.

I tried the other methods people did of unticking boxes and doing random stuff.

If you want to truly eliminate the DNS requests from leaving the router, do the following:

nano /jffs/scripts/hosts.postconf

#!/bin/sh
CONFIG=$1
. /usr/sbin/helper.sh
pc_insert "127.0.0.1 localhost.localdomain localhost" "131.107.255.255 dns.msftncsi.com" $CONFIG

save, and reboot.

This will add it to the hosts file which will be checked before an outbound dns request.
The only downside is as others say, you can't use dns based down-detection any longer, which means Dual WAN will be affected.
And your router will always say it is connected to the internet.

The issue is null values. The behavior now is to restore default values silently behind the scenes rather than allow null values to persist here. You can achieve the same behavior of disabling the probes by simply enabling the probe and setting the host to localhost and the content to 127.0.0.1 without resorting to low level hacks like this.

That has the added benefit of being readily apparent in the UI so when you go to troubleshoot something later you don't have to dive into the filesystem to hunt down custom scripts you've thrown into the mix a year ago or whatever. Or having a persistent JFFI or shell access at all.

 

[eibgrad]

That said, I don't like this opaque, undocumented behavior where the values you configure are silently ignored for alleged harm reduction. If someone wants to stop the probes, the device should respect that and not have any further opinions on the matter. Part of using something like asuswrt-merlin is to have more control over the device. Having hidden behaviors that run counter to what the user expected to happen in an effort to save the user from themselves seems like an antipattern. Especially when it comes to unexpected traffic.

Amen. But there's an important caveat here.

I assume this is behavior imposed by ASUS, NOT @RMerlin. And that's really two different situations. I expect things like this from the OEM, and that's why we so often turn to third-party firmware. And when the above statement makes the most sense.

But unlike other third-party firmware, Merlin is NOT a wholesale replacement for the OEM firmware. It's more of a hybrid, which only offers extensions and/or enhancements. So while I agree w/ the above statement in principle, you have to realize you're going to be stuck w/ certain design decisions imposed by the OEM whether any of us (or Merlin) like it or NOT.

Like any third-party firmware, they all come w/ advantages and disadvantages, pluses and minuses. And when choosing among them, this is something you have to consider. It's why Merlin can't just decide one day that he'll add support for user-defined features like VLANs and VAPs, or place all the guest networks on their own IP networks, or a plethora of other things I'm sure many of us would like to see. He's constrained by the OEM.

 

[SomeWhereOverTheRainBow]

You don't need to do that. You can just set dns_probe_host to "one.one.one.one" and dns_probe_content to "1.1.1.1 1.0.0.1 2606:4700:4700::1001" to achieve the same results of using Cloudflare instead of Microsoft without having to resort to any sort of shenanigans that might cause issues down the road. You can do this via the web interface too.

What was changed was if you null out either field (or at least dns_probe_content) the firmware will silently restore the default values behind the scenes, outside of your visibility. You can change these values to other things, like dns_probe_host to "localhost" and dns_probe_content to "127.0.0.1" and it will effectively stop the probe requests from leaving the device without modifying your hosts file.

This seems to be asuswrt-merline behavior only, not behavior from upstream. I understand the motivation Merlin had behind this change was to reduce the support burden coming from people that nulled out the old values to stop the probes but then forgot about it and later come to the forums wondering why things like failover stopped working.

That said, I don't like this opaque, undocumented behavior where the values you configure are silently ignored for alleged harm reduction. If someone wants to stop the probes, the device should respect that and not have any further opinions on the matter. Part of using something like asuswrt-merlin is to have more control over the device. Having hidden behaviors that run counter to what the user expected to happen in an effort to save the user from themselves seems like an antipattern. Especially when it comes to unexpected traffic.

If we're insisting on keeping this behavior, what is happening should be readily apparent in the UI and nvram states. They should always reflect reality and not hide what the behavior will be.

As a user:

• if I disable the "DNS query" network monitoring I expect the device not to make DNS queries for the monitoring domain.
• if the network monitoring behavior can't be stopped, I expect the DNS query checkbox to not be modifiable.
• If the "resolve hostname" or "resolved IP adresses" fields cannot be empty, I expect an error message when saving the form and the default/previous values be restored in the UI.

Hey just because it isn't your solution, and doesn't break default router behaviors, you shouldn't dismiss some one else's suggestion. It will do what the OP is expecting which is prevent those request from flooding nextdns. And that is the only reason the solution was provided. It was not provided to start a separate chain of peanut gallery commentary from another user wanting to say my solution is bigger/ or better than yours.

 

[dephekt]

Hey just because it isn't your solution, and doesn't break default router behaviors, you should dismiss some one else's suggestion. It will do what the OP is expecting which is prevent those request from flooding nextdns. And that is the only reason the solution was provided. It was not provided to start a separate chain of peanut gallery commentary from another user wanting to say my solution is bigger/ or better than yours.

It's not a dismissal, it's just saying there's a simpler way to do it which is true. You don't need to be offended by it and it wasn't intended to be a "haha this is better than your idea" sort of thing. It's a "I've looked into this a lot and there's an elegant way to solve this that doesn't resort to modifying the filesystem." Feel free to do it or not. The thread is a discussion about this issue and you're not the only one allowed to throw out potential ways to solve it.

 

[homenetworkyeet]

The issue is null values. The behavior now is to restore default values silently behind the scenes rather than allow null values to persist here. You can achieve the same behavior of disabling the probes by simply enabling the probe and setting the host to localhost and the content to 127.0.0.1 without resorting to low level hacks like this.

That has the added benefit of being readily apparent in the UI so when you go to troubleshoot something later you don't have to dive into the filesystem to hunt down custom scripts you've thrown into the mix a year ago or whatever. Or having a persistent JFFI or shell access at all.

That's a very pertinent point. As RMerlin advises the best thing to do is avoid tampering to prevent future releases from conflicting with all sorts of various user configurations. If it shows up in DNS logs like pi-hole then you can exclude that from the logs just fine as the function does serve a purpose. An option to configure the probe time in the GUI would be handy.