Sense and spurious external DNS access

So I recently installed some new rules on my home firewall. One of those is to block all attempts to access external DNS services. All devices should be using the DNS supplied via DHCP. Once I did I noticed my sense monitor continuously tries to contact CloudFlare DNS at
Found an article explaining they do that and, if it fails, they fall back on the DHCP provided DNS. As a result, even though everything ends up working fine, I get lots of messages about this blocked DNS access attempt.
It seems to me that this is the wrong order of things. I can totally see trying a fall back on of the internally supplied DNS does not work, but not the other way around.

1 Like

I agree.
The whole idea of running a local resolver is to save bandwidth, improve response time.
Local first, if that fails try external dns

I just looked at my resolver logs
16,304 requests in the last 7 days.

You can make a support request to opt out of the ClourFlare DNS override.

See this link for info.

1 Like

Yes, I know that, but… it is a useful safeguard against misconfiguration, so I would keep it, but still I believe the order should be reversed.

With all that said, I modified my firewall to redirect all external DNS access to my internal, so sense thinks it is accessing but actually gets mu internal, which in turn uses DNSSEC and DNS over TLS to limit leakage.


So sense contacted me to suggest they switch of the access. I re-iterated that the problem is that they should only do that if local DNS fails to resolve to working servers, and asked them to forward that to engineering. Switching it off altogether is not advisable due to it being useful for DNS misconfigurations. We’ll see what happens, but I am not hopeful.

Meanwhile I’ve setup my firewall to redirect such attempts to my local firewall anyway. Consequently sense attempts to contact first, without its knowledge it gets port forwarded to my internal DNS, which resolves it correctly, and returned as an answer seeming to come from Sense does’t ever attempt to directly use the internal DNS. This setup will be out of reach for a very large percentage of owners though!


Same setup I have.
I also have pi-hole dns filtering added to my resolver.
Love it!

Sorry, but I have disagree with you, and I would object if Sense took this approach. It’s arguably worse than what they do now.

A hard coded backup server in case DHCP doesn’t declare a server is one thing, but having a client fall back to asking an external server if the local server returns some form of not found is a bad idea. If severs are declared in the DHCP response they should be used exclusively.

1 Like

Perhaps I did not word my issue precisely enough or you. What I mean is this:

  • If DHCP advertises a DNS resolver, it should be used
  • If DHCP does not advertise one, fallback on a hard coded one is OK, and perhaps even advised
  • It is never OK to use a hardcoded one, when DHCP advertises a specific one, but this is what sense does

Ignoring/bypassing an advertised DNS resolver goes against all basic networking principles and takes some control of one’s network away.


While I may personally agree with this, it should be noted that many do not. Using hardcoded DNS server addresses has become commonplace for many consumer devices. [For many years, if one wanted a Google Home certification for a device, the device was required to use as its primary DNS regards of DHCP.] Hardcoded DNS has also become common in browsers these days. People who mandate this argue that it is both for reliability and for security.

1 Like

For browsers it is mainly to “tie” the user to a particular provider (google) so that more tracking and ad-serving is impossible/harder to stop. It is obvious why such would be in the interest of the parties doing it. For years Microsoft mandated all kinds of requirements from PC makers regarding their OS. Understandable from a protection/profit motive, but wrong and they eventually lost this in court.
That is another way of saying that just because it happens, or is being done, does not make it right.

For iOT devices, I think it makes sense as a fallback, because it increases the odds of the device working despite a possible misconfiguration on the user’s network. Here too the motive can also be tracking. Chromecast is a good example. They want to know what you are watching and when and tracking your DNS requests is a great tool for that. Should they? No!

It is very effective protection of a network (although not 100%) to disallow all outbound DNS, in particular to stop malware access to CC servers. Setting this app will defeat these browsers and iOT devices original intent, yet the should still work, and most do. That too proves to me that the motives are not pure, at least with the end-user’s needs in mind.