> Side note: for those wondering, Tailscale is Canadian and can't see the content of connections (although if you're worried about this it's also possible to self-host using Headscale).
However this is no longer the case. From Tailscale's Terms of service "Schedule A", "New customer accounts on or after September 3, 2024" are bound to "Tailscale US Inc., a Delaware corporation"
> I never want to send any fraction of information about my Internet browsing to Tailscale.
I'm slightly confused about this part of the ticket. If you're using Tailscale DNS, how do you avoid sending Tailscale information about your internet browsing?
You can't.
Can you elaborate on what you actually mean by this? Headscale works fine.
This is not a bullet proof solution in case there is a semi known custom DoH an application use. But it is the best that I can do without Enterprise network gear and more complex setup that I would like to maintain.
You can also force the browser to behave in "corporate" mode, where DNS requests are analyzed by the corporation (you in this case) to determine which domains can and which cannot be accessed by employees (you and your family in this case).
Here for Firefox:
https://support.mozilla.org/en-US/kb/firefox-dns-over-https
"This article describes DNS over HTTPS and how to enable, edit settings, or disable this feature."
Notice the "or disable this feature".
You change the "trr" value (trusted recursive resolver) and DoH is not supposed to happen anymore.
Setting the browser to not use DoH and blocking known DoH servers is great.
What I wonder is if can then easily configure my DNS resolver (I run unbound) to itself use DoH: I don't have anything against DoH. What I have something against is not being able to blocklist based on domain names.
Why trust the wires at all. Just run all traffic through VPN, even if it's in the same LAN.
This way, I know all traffic is encrypted. I don't have to worry about SMB or the like being plaintext.
I could probably tweak it, but I haven't had the bandwidth (ha) to troubleshoot it.
Can't an attacker spoof an IP and do SSRF? Or is nginx too good at detecting those kinds of attacks?
The attacker would have to be on the local network, in which case the attacker isn't really bypassing the allow rule, because the allow rule is intended to allow anyone on the local netowkr.
[0]: https://simpsonian.ca/blog/securing-home-network-dnsmasq-tai...
leipert•7mo ago
Can’t you force traffic to 8.8.8.8 / 8.8.4.4 (especially port 53) to hit your PiHole instead?
joombaga•7mo ago
temp0826•7mo ago
Melatonic•7mo ago
VTimofeenko•7mo ago
(nftables syntax)
ip saddr != @lan_dns ip daddr != @lan_dns udp dport 53 counter dnat ip to numgen inc mod 2 map { 0 : 192.168.1.1, 1 : 192.168.1.2 } comment "Force all DNS traffic to go through local DNS servers"
watersb•7mo ago
I've tried to add a couple of rules in iptables on my Ubiquiti Dream Machine (UDM), but the out-of-box configuration on the UDM is pages and pages to iptables rules. I can modify that config via a shell interface (a shell script with four iptables command lines), but it doesn't play with the web based GUI, and I have yet to figure out how the UDM handles such traffic.
Yes, I've simply blocked all traffic for 8.8.8.8 and 8.8.4.4, via the UDM GUI, the rules are there. The Kindle still shows me ads.
It may be possible to delete the entries for Google DNS on the Kindle via adb commands during boot, but I haven't gotten that far.
Someday I will get around to setting up a homelab network enough to learn iptables etc without blacking out my home network. As any network outage bring immediate screams from the house, I have to treat the firewall configuration as critical infrastructure: brittle. Don't touch.
ectospheno•7mo ago
OptionOfT•7mo ago
api•7mo ago
gerdesj•7mo ago
Then in the name of ... something, something, security ... DNS over http(s) was invented. Now you can balkanize DNS by requiring certain SSL certificates be involved. To my knowledge this hasn't been abused large scale yet but it could.
Let's go easy on the tinfoil and simply redirect outbound traffic to 53/udp and tcp to a PiHole or other DNS server under your control.
If you insist on the tin foil, you will probably need to look into a MitM proxy such as Squid - look into "bump" and "spice".
esseph•7mo ago
It looks like a web request, which was literally the point of the specification.
"DoH ensures that attackers cannot forge or alter DNS traffic. DoH uses port 443, which is the standard HTTPS traffic port, to wrap the DNS query in an HTTPS request. DNS queries and responses are camouflaged within other HTTPS traffic, since it all comes and goes from the same port."
Now if you get into that territory, as you have suggested with your proxy comment, now you are breaking the security model for not just DNS requests but much of the overall traffic on the network.
vladvasiliu•7mo ago
You may be breaking things altogether, actually, since many of the devices for which this song and dance needs to exist don't actually offer a way to alter certificates. I don't know that my smart tv actually uses DoH (it's not physically connected to the network), but I have no idea how I'd add a trusted certificate to its chain, even for other purposes.
gerdesj•7mo ago
Your browser could require via TLS certain CA only signed responses and even covertly do that and flatly refuse to use the system configured DNS and fib and lie. At least DNS over UDP/TCP can be easily manipulated locally through a packet filter and via NAT n that and it can be inspected by the end user easily.
No, I am not suggesting you break any security model - a MitM run by yourself is yours and yours alone. If you consider your browser might be hostile <tin foil crackling sound effect here> then you really have to look quite deeply into what security model you are dealing with and how it really works.
Proxies and so on are just tools for a job as are DNS servers (I have one just for my customer's Let's Encrypt challenges) and all the rest.
I like to forget the usual trite networking bollocks and think quite clearly about how it all really hangs together. I start with what I would like to be the source of "truth" with regards the thing I type into the browser and the IP address that is returned and connected to.
1oooqooq•7mo ago
It's the same reason why they reverted silently the options to disable referrer (the default since chrome took over is now to send full url even on xdomain, which was unthinkable during mozilla vs ie)
anything that impacts delivery of ads (dns on android/chromecast) or attribution (referrer) will be fought against by google.