how do you know the one they are asking for is the correct one?
You will always behind and even if you spend a lots of time you will realize that many of the crappy/sh!tty "smart" devices work with the principal "eat or die". So in the end it comes down if you are confident enough to use it with all the "anti features" (like tracking etc.) or you don't use them and turn them into a 
.
I also really wonder if you already thought about your other "smart" devices like phones 
. They are very well known collect any possible data of you. Just an idea what apple and google like to know about you:
We find that even when minimally configured
and the handset is idle both iOS and Google Android share
data with Apple/Google on average every 4.5 mins. The phone
IMEI, hardware serial number, SIM serial number and IMSI,
handset phone number etc are shared with Apple and Google.
Both iOS and Google Android transmit telemetry, despite the
user explicitly opting out of this. When a SIM is inserted both
iOS and Google Android send details to Apple/Google. iOS sends
the MAC addresses of nearby devices, e.g. other handsets and
the home gateway, to Apple together with their GPS location.
Users have no opt out from this and currently there are few, if
any, realistic options for preventing this data sharing.
Over 99% of users typically bite the bullet (or bitter apple 
they say in german) and only a fraction tries to lower the collection fever from the manufacturers.
There is also literally nothing you can do on a apple device to stop this, not in your router and not in your phone. All or nothing.
1 Like
There are lists of IPs of DoH servers on the Internet. (example)
These would have to be blocked in the firewall with port 443.
There are not that many servers - it is basically enough to block the large providers, since they are most likely the fallback from the smart devices.
Therefore, it also makes sense to implement a rule for classic DNS that blocks all traffic on port 53 except to your desired server. You can also go a bit further and secretly redirect all traffic on port 53 to your DNS. This way the devices think they are communicating with 8.8.8.8, but instead they get the replies from the local pi-hole.
Even if this (incomplete) list and DoH wouldn't be a problem it comes down that you (@GMB) play the cat and mouse game. Thing is you will always be on the loosing side as manufactures have ways (source code, infrastructure, resources, ...) to just always be ahead of you.
There is simply no way to to trust not trustful (crap) devices even a little bit.
Instead of investing a lot of time trying to partly mitigate anti features of sh!tty devices you should rather focus on not getting more of them and (slowly) migrating to trustworthy (local, open source) solutions like you did with your decision for openwrt 
That's the only way..
2 Likes
This is entirely dependent on your perspective -- a user or an admin.
From the user perspective, this is a significant improvement over standard DNS. It provides an improvement in privacy with respect to dns queries -- the connection between your device and the DNS resolver is encrypted which means that people in the middle (such as ISPs, governments, etc.) cannot peer into your requests (although they can still see the IP addresses you visit post-DNS resolution). But maybe more importantly, it secures the DNS system from redirection attacks. Using a pihole as an example, I could redirect your queries to another address and potentially phish your credentials (ssl/tls websites do help prevent this to a degree, but people don't always notice if a site isn't actually https).
Obviously, as an admin, this is a harder situation since it severely limits the dns monitoring and filtering capabilities.
1 Like
Probably the most secure way to do it is to use the firewall to block everything except the Ip addresses of the servers you allow. You will have to update if the ip changes, either manually or through a script. Even with encrypted dns, it can only communicate with the ips you choose.
For home automation, i suggest flashing your devices with a custom firmware like tasmota and running a local server like homeassistant. This can keep everything local to your network.
If you need remote access you can use zerotier.
I just think that DoH using the usual https port was a deliberate decision to make it hard to stop. The other encrypted DNS system has its own port - much better.
My concern with all this is growing because "don't buy it" is a dying option. For example I understand that homes with electric car chargers are obligued to give them an Internet connection. And I suspect that the replacement for our mangy central heating boilers may need to be controlled over the Internet so I need a way to make it visible without it getting ideas about doing its own surfing. The trouble with WiFi and DHCP is that once a device knows the password it gets given too much access. Having a little OpenWrt access/router will let me keep it at arms length. And I think I will try pi-hole running on my rPi server.
Any reasons for that? Don't think so.
But guess, I can control my water heater over the internet, also most of my lights, fans, water pump and most other stuff in and around my home.
Did I ever use it? Kind of never, I think once (like 2 years ago) turned my water heater on from remote when we came back from holidays so we directly had warm water arriving late and could have a hot shower.
Actually I retrofitted my "dumb" hot water heater with like $10 hardware and refined it with a open source firmware (esphome). Actually all my "smart" stuff runs open source software.
does the rest combined with my openwrt managed network. So I got (in theory) wireguard to access my home network but in reality it almost never (can't really remember the last time) get's used. But because I use open software (no vendor lock!) I set up signal on my home assistant server which is quite convenient (E2E encrypted communication without vpn). I get snapshots from my (local only) camera 
if motion is detected (it also works as a automatic bell at home and plays a chime on the stereo system 
) Also it's possible for me to "talk" and ask like the warm water temperature (solar) for example.
And all this without depending on any sh!tty manufacture (and their limited possibilities). You don't own crap (or data) when you rely on cloud services (which can btw. vanish from time to time or just start to have a subscription fee). To depend on other peoples computer for stuff in your own home is surely one of the most stupid invention we had in the past.
But sure, go ahead if you think you need the crap just buy it and get happy in the golden cage 
You will just end up with limited possibilities and wasting your time trying to tame the beast - good luck 
1 Like
I think we can stick to the technical discussion rather than debating the good and bad of this particular approach. Let me paraphrase OP's need:
- block/redirect outside DNS and DoT/DOH to force local resolve
- stateful IP allow-listing based on DNS responses
This is basically what happens on a paid wi-fi access point before you pay. When you send DNS request to the whitelisted domain names (e.g., maps.googleapis.com), the response IP address is allowed.
I think this works reasonably well (it blocks off a lot of actual human being and trick them into paying!) so it's quite worthwhile to implement it. Although easy to bypass, it's still meaningful. I always bypass it by manually sending a request to get a Google IP whitelisted, and start a SSL connection to that IP to access gmail etc.
I believe the feature I mentioned is commonplace builtin feature of some ubiquiti/aruba commercial-grade wi-fi controllers. Not aware of any open-source solution though -- it needs a tight coupling between the DNS resolver and the firewall. Maybe pfsense works. Hacking OpenWRT is definitely an option but you probably will need to write a custom script to monitor and parse DNS resolve logs (from dnsmasq) and add iptables rules in real time, and also expiring those rules.
That's interesting about how the WiFi access works. I had always wondered.
I can see I will have some work to do. I had hoped it would have already been done.
MangoMan completed misunderstood. The whole point is that I will NOT be using cloud service access routes because I have my own little cloud but if I let a "smart" thing get a wiff of the outside world it will surely go after its home. But they may need to be accessed locally. Also anything offering a handy service like a browser I might want it to work, but again while keeping it away from its home base.
I think the biggest problem to this approach is how do you know what they're doing?
If you let it access 123.123.123.123 on port 443 for an https connection, it can now do whatever it wants. DNS over https, send data to corporate headquarters, send video of you peering into it's camera, record voice, send usage data... Whatever. It's an encrypted connection, you have no idea what it is doing. All it needs is one ip and one port. Everything goes over https these days.
2 Likes
That is my whole point. With my scheme it can't access 123.123.123.123 unless my DNS has given out that IP from a whitelisted name. That is why I want to link the routing rules to the restrictive DNS.
This is my network setup. Similar build and can do what you want.
Yes. This can be done in PiHole. It has Group Management feature.
Executing command in the CLI: pihole -t will let you see DNS queries and block request in real time.
All DNS request are being handle by PiHole.
PiHole has a query log that you can see what successful/blocked request from each IP. You can also run Unbound together with PiHole.
For website like TikTok, PiHole can only partially blocked it since it seems that from a PC it works, but from mobile app is a different ball game. In order to block it you will need IPTables to completely blocked it. Tcpdump will come in handy.
The above network topology works for me in total control of my home network.
Hope this helps.
well, suppose you whitelist "service.myfancyiot.com" which points to 123.123.123.123 and is the thing your IoT device needs for it to do its useful work. Now it has unlimited access to anything. it can set up a VPN through 123.123.123.123 into the cloud network of the mfg and from there it can request anything it wants.
So as soon as you open even one IP and port combo it might as well be the whole internet.
1 Like
Or like the new IoT crap which just starts to work on frequencies (60.5 GHz) your router doesn't talk 
Well the base station still needs a way to reach the Internet so I am not sure that the 60.5Ghz link matters. But I think I will be blacklisting any fruit-based technology anyway.
Yes, that is the concern - but only if the IP in question is "multi role". Big search engines may become even more sinister than they already are by offering such services.
I guess my point is it's trivial to punch a truck sized hole if you are given only one IP and one port. Whether the device does this or not is not something you are in a position to easily evaluate as the connection will be encrypted. It then becomes "trust entirely" or "block all internet".
For my IP cameras they are entirely blocked from outbound connections. My cell phone unfortunately I still put up with ... All my home automation stuff is ZigBee and connects to a RPi running home assistant, so none of that is internet connected... Beyond that forget it. I won't have Alexa or the like. I might go with Mycroft when the server can be self hosted.
3 Likes