What's new

dns.msftncsi.com flooding my NextDNS

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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.
Obviously I wouldn't expect mine to be the only solution. And I would expect others to respect that in their replies to others responses. Notice I was proposing my solution to the OP, not other people's suggestions, which would be the appriate way to propose ones solution.
 
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.
What I was saying came from Rmerlin himself here (quoted below):

A number of the reports in the 386.4 beta cycle were due to such people who had manually fiddled with the nvram settings related to this, forcing me to implement some form of fallback handling for these cases (i.e. restoring a sensible default value if the user had wiped that default value).

While I can empathize with the desire to prevent self-harm, and I don't think restoring the defaults is itself a bad idea when one of the values is nulled out, I think the fact it's hidden away from view is perhaps needlessly problematic and a problem that can probably be solved downstream here with some additional UI/UX changes or documentation.

I had to spend a lot of time with this earlier today tracking down why I was seeing Microsoft requests in my DNS every few minutes when my network has only Apple, Android, and Linux devices connected. It was exasperated by the fact when I go into the router settings the DNS probing was not enabled (I had never changed the setting before). I finally assumed it was a firmware bug that the UI and nvram configuration for this feature wasn't being respected, so I started searching where to report bugs, found this forum, and searched for the domain in the posts until I found recent threads about this and found a definitive answer from the maintainer. It shouldn't take that much effort to understand how this was intended to work and why :p

Ultimately it's just a DNS request using my normal DNS servers that I already extend trust to, so it doesn't really matter to me that it happens. I don't think any data is being transmitted to Microsoft, it's just asking my DNS server to resolve the IP and confirming that it matches what was expected. I just have tools to monitor the DNS requests happening on the network and the Microsoft domain caught my eye and I wanted to understand where it was coming from and why mostly out of curiosity.
 
Last edited:
I also don't understand why Asus needs to implement this even if you are using single wan. I use to blank this out on 386.3.2 otherwise my dns server will be filled with this. Unfortunately you can't blank this out on 386.4, since you will encounter the disconnected issue on network map.
 
I also don't understand why Asus needs to implement this even if you are using single wan. I use to blank this out on 386.3.2 otherwise my dns server will be filled with this. Unfortunately you can't blank this out on 386.4, since you will encounter the disconnected issue on network map.

Apparently the way to deal w/ this isssue now is to go to Administration > System > Network Monitoring > DNS Query, and set "Resolve Hostname" as "localhost" and "Resolved IP Addresses" as "127.0.0.1".
 
Apparently the way to deal w/ this isssue now is to go to Administration > System > Network Monitoring > DNS Query, and set "Resolve Hostname" as "localhost" and "Resolved IP Addresses" as "127.0.0.1".
if you do it that way, will network map still show connected even if your actual wan link is down?
 
if you do it that way, will network map still show connected even if your actual wan link is down?

Yes. You can't have it both ways. Either you allow it to check on a regular basis that your link is up and working, and have it accurately reflected in the network map, OR, suppress the constant network activity but then have no means for the router to detect the actual loss of connectivity (i.e., it will always assume connectivity is established). Again, it's one or the other.
 
I also don't understand why Asus needs to implement this even if you are using single wan. I use to blank this out on 386.3.2 otherwise my dns server will be filled with this. Unfortunately you can't blank this out on 386.4, since you will encounter the disconnected issue on network map.
Exactly, this is more applicable for dual Wan networks that needs fail over service to determine Wan's status not for a single Wan. This is a shotgun approach they implemented. :(
 
Apparently the way to deal w/ this isssue now is to go to
Administration > System > Network Monitoring > DNS Query, and
set "Resolve Hostname" as "localhost"
and "Resolved IP Addresses" as "127.0.0.1".

Even after doing this change, I am still getting these queries ...

Prior to change..
Screenshot 3.png


Changed:
Screenshot 2.png



Value checked in NVRAM
Screenshot 4.png



Queries still being pushed upstream to my Cloud Hosted DNS server (AdGuardHome)
Screenshot 1.png


Anyone have a final fix that works?
(I understand the caveat that WAN detection will not work as expected)
 
Apparently the way to deal w/ this isssue now is to go to
Administration > System > Network Monitoring > DNS Query, and
set "Resolve Hostname" as "localhost"
and "Resolved IP Addresses" as "127.0.0.1".

Even after doing this change, I am still getting these queries ...

Prior to change..
View attachment 39598

Changed:
View attachment 39599


Value checked in NVRAM
View attachment 39600


Queries still being pushed upstream to my Cloud Hosted DNS server (AdGuardHome)
View attachment 39601

Anyone have a final fix that works?
(I understand the caveat that WAN detection will not work as expected)

When I'm configured w/ localhost & 127.0.0.1, tcpdump clearly shows NO activity over the WAN for dns.msftncsi.com.

Code:
tcpdump -vv -i $(nvram get wan0_ifname) udp port 53 or tcp port 53

And NO DoT of any kind, either from ASUS or NextDNS.

Normally if that was happening, it would be every 15 seconds. But you're showing requests being made much less often, and variably (2 mins, 5 mins, 1 min). That makes me think the source of these DNS requests is NOT the ASUS WAN connectivity check, but something else, perhaps even the NextDNS process installed on the router.
 
Last edited:
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
This is the only solution that has worked for me....

Other suggestions reduced the queries from the logs but did not totally stop them - but this just gets rid of them completely (as expected @SomeWhereOverTheRainBow )
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top