Dns.msftncsi.com and asus router

I’ve an Asus router which queries to dns.msftncsi.com every one second, which tells my router to switch to secondary LAN, if my ISP is down for more than few seconds. It’s an essential part of my failover strategy.

Now, every time I log into my dashboard, I see my asus router’s host name in top client’s list.

How do I get my router off this logging?

I’ve already whitelisted domain dns.msftncsi.com and wondering if there’s a way to exclude router.asus.com hostname from logging stats as it’s only active DNS query to Microsoft’s server seems to overshadow query logging of clients connected to router.

If this is an essential part of your failover strategy, it appears to be something you have either set up or want to retain. Why is this an essential part of a failover strategy?

Queries to this domain coming from the router should not be unusual, given the circumstances.

If this is an essential part of your failover strategy, it appears to be something you have either set up or want to retain. Why is this an essential part of a failover strategy?

Here,

Screen Shot 2021-04-08 at 9.57.59 AM.png

Asus’s router uses active DNS queries to determine whether internet is up with a given ISP.

— —

Queries to this domain coming from the router should not be unusual, given the circumstances.

Yes, queries coming from router shouldn’t be unusual, but it seems to fill up my log file with per second query to dns.msftncsi.com, thereby overshadowing DNS queries from other clients. To give you a perspective, imagine 7 entries of dns.msftncsi.com and then 1 entry of gds.google.com. At the end of day I’ll be looking at a minimum of 86k+ entries in my logs from msftncsi alone, with few additional hundred/thousand from connected clients, if that makes sense.

What I’m trying to do here is to tell Pi-Hole to not log queries from dns.msftncsi.com

All queries are logged equally per your privacy and logging settings. If you log one domain, you log them all. There is no option to selectively not log a domain.

I see your router offers an option to check network status by pings rather than DNS queries. Have you tried that option?

Have you ever had a WAN failure that caused the router to jump to another WAN?

I see your router offers an option to check network status by pings rather than DNS queries. Have you tried that option?

This is what is stated in Asus’s documentation -> https://tldrify.com/138o (I did a 24 hour ping test and there was certainly timed out requests upwards of few seconds because certain nodes within my ISP’s network didn’t like me polling a ping every second)

Although that brings up a new question - would you say I’ll be affected by the following, should I choose to use DNS query with Pi-Hole -> “ In the certain circumstances, DNS queries work because DNS information is stored in the cache of your device even if your router is not connected to the Internet.”

Have you ever had a WAN failure that caused the router to jump to another WAN?

Yes. As a matter of fact a low tier secondary WAN has always come to rescue of my ISP’s WAN fails intermittently due to harsh weather, particularly during rains/thunderstorms.

Make your router use an other (public) DNS server for all of it's queries. This way no queries of your router will go to Pi-hole and spam your logs.

Elaborating on yubiuser's suggestion:
You'd likely have to switch your router's upstream DNS servers from Pi-hole to public ones.
Of course, this is only a viable option if you have configured your router to distribute Pi-hole as local DNS server via DHCP, and as longs as you don't have to rely on router upstreams to point to Pi-hole for other reasons.

If you have to keep Pi-hole in the loop, consider to tune your polling interval to the TTL of the domain you are using for the test.
There is little use in polling a domain every second when its TTL e.g. is 60 seconds: As Pi-hole will be caching the DNS record for the TTL, you wouldn't be able to detect a failure before the TTL has expired and the record has been removed from its cache.

A dig for the domain will reveal the current remaining TTL in the ANSWER section, just before the IN keyword, e.g. 30 seconds for

;; ANSWER SECTION:
dns.msftncsi.com.       30      IN      A       131.107.255.255

Note that if you'd repeat the same dig e.g. 5 seconds later, TTL would read 25 seconds.