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 1.1.1.1.
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 1.1.1.1 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 1.1.1.1 but actually gets mu internal, which in turn uses DNSSEC and DNS over TLS to limit leakage.
2 Likes
So sense contacted me to suggest they switch of the 1.1.1.1 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 1.1.1.1 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 1.1.1.1. 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!
2 Likes
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.
2 Likes
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 8.8.8.8 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.
4 Likes
Hi @dolfs,
Another recent post reminded me that Sense had posted this on DNS Policy quite a while ago:
It is our experience that these servers offer more dependable service than a home network’s DNS server.
Really ?
Any prove for that ?
I call that baloney
Additionally, misbehaving home DNS servers are usually beyond the technical ability of many home users to diagnose and fix.
You mean as in
“if the resolvers are down, you can not reach anything on the internet”
Yeah, really hard to diagnose …
Thanks for that. When I initially wrote my post I looked for stuff like that, but apparently did not look back far enough. Still think they did this wrong:
For a very, very large percentage of home users the local DNS will be configured through the setup of their cable/fiber/whatever router, which 99.9% of the time does not get modified from defaults, and forwards DNS requests to the upstream DNS servers provided by the Internet provider. As such, they will not be misconfigured, although it is debatable whether those ISP provided DNS resolvers are the very best choice. Thus, using the DHCP configured DNS resolvers (which are often just forwarders), should work just fine.
People more like me (will be rare occurrences, although may be not so much in this forum), and will configure a different DNS setup locally. Typically to secure DNS, protect against malware penetration etc. These kind of users generally know very well what they do, and again DNS is unlikely to not function as provided through DHCP.
Now, when the sense devices wants to resolve something and if it would use the DHCP provided setup, it will either get a real IP address, or it will fail to resolve. The former is, 99.999% going to be correct (it requires a specific and deliberate act, somewhere, to deliver the wrong ip address). The latter would indicate some failure, either because of DNS misconfiguration locally, somewhere down the chain towards the TLD name servers, or a network glitch. In that case, and it is my contention only in that case, is a retry using 1.1.1.1 (Cloudflare) reasonable in order to attempt to keep the device functioning.
I do agree that despite that, it should be something configurable, but an initial “on” setting (i.e. requiring an explicit opt-out) is reasonable. Since this is not currently configurable, sense offers to switch it off altogether, if you ask. That is not quite the right solution either, for the reasons above.
2 Likes
It is our experience that these servers offer more dependable service than a home network’s DNS server.
Really ?
Any prove for that ?
I call that baloney
I do to. See my earlier reply. Now my professional experience is only about 40 years long so I might have that wrong 
Additionally, misbehaving home DNS servers are usually beyond the technical ability of many home users to diagnose and fix.
As I have stated, 99.999% of these are configured by/through ISPs and will not be misbehaving (much anyway). Typical home users don’t even know what it is, so will not attempt to re-configure and in the process screw it up.
You mean as in
“if the resolvers are down, you can not reach anything on the internet”
Yeah, really hard to diagnose …
Yes, that is typically what the result will be if misconfigured, and typical symptom will be that “nothing” works. Except sense, because they hard-code using Cloudflare. Again, for that scenario, I am ok with it, but only if “normal” DNS use completely fails.
1 Like