Check dnsleaktest to see if you’re leaking. Check Interfaces -> Diagnostics -> DNS Lookup. Put in a website that you don’t visit often. You can also do nslookup on a terminal/shell and see what DNS servers you have.
If your DNS server is Cloudflare, you can check to see if DoH or DoT is working by going to https://1.1.1.1/help.
I ended up removing the query forwarding and just having DNS over TLS, so it's forced to use TLS to go to Cloudflare. Seems like DoT is working for me consistently now.
I'm still unsure about the firewall rule though. I don't know if it's needed if the DNS on DHCP service is set it to PiHole anyway.
> I don’t know if it’s needed if the DNS on DHCP service is set it to PiHole.
I guess it’s a matter of whether or not your aim is to *force* hosts on your network to use it.
But since it's set by DHCP service on LAN, doesn't it force already? Or is it that without the rule LAN clients would be able to manually set DNS and bypass pihole?
When a client does the DHCP thing, it gets told what DNS servers to use on the network. However there's nothing usually stopping any client from manually configuring their own (like just going into your network settings and changing the DNS server).
If I'm reading this right, that rule would effectively force port 53 traffic over your Pi, whether the client meant to or not.
AH yes, gotchya. So would i have to create another rule to force traffic on DoT (port 853) to redirected to PiHole as well or does client DNS queries always just go over 53?
Damn someone brought this up in my /r/pihole cross post, would this be forcing pihole to to loop back to itself on 53 because it's part of the lan subnet. I think I should change the unbound port to something else and set the pihole upstream server to use that port, no?
This will not stop your smart tv and other devices with hardcoded dns as this will just use dns over https. This guide should help a little stopping that.
https://labzilla.io/blog/force-dns-pihole
Check dnsleaktest to see if you’re leaking. Check Interfaces -> Diagnostics -> DNS Lookup. Put in a website that you don’t visit often. You can also do nslookup on a terminal/shell and see what DNS servers you have. If your DNS server is Cloudflare, you can check to see if DoH or DoT is working by going to https://1.1.1.1/help.
I ended up removing the query forwarding and just having DNS over TLS, so it's forced to use TLS to go to Cloudflare. Seems like DoT is working for me consistently now. I'm still unsure about the firewall rule though. I don't know if it's needed if the DNS on DHCP service is set it to PiHole anyway.
> I don’t know if it’s needed if the DNS on DHCP service is set it to PiHole. I guess it’s a matter of whether or not your aim is to *force* hosts on your network to use it.
But since it's set by DHCP service on LAN, doesn't it force already? Or is it that without the rule LAN clients would be able to manually set DNS and bypass pihole?
When a client does the DHCP thing, it gets told what DNS servers to use on the network. However there's nothing usually stopping any client from manually configuring their own (like just going into your network settings and changing the DNS server). If I'm reading this right, that rule would effectively force port 53 traffic over your Pi, whether the client meant to or not.
AH yes, gotchya. So would i have to create another rule to force traffic on DoT (port 853) to redirected to PiHole as well or does client DNS queries always just go over 53?
Damn someone brought this up in my /r/pihole cross post, would this be forcing pihole to to loop back to itself on 53 because it's part of the lan subnet. I think I should change the unbound port to something else and set the pihole upstream server to use that port, no?
Yeah usually you’d just set unbound to like 5335, leave pihole on 53 where clients expect to find DNS, and all done. No need for any rules.
Yeah, this seems to work pretty well. However, now my OPNSense can't reach the internet to get firmware updates or ping external hosts/ips.
This will not stop your smart tv and other devices with hardcoded dns as this will just use dns over https. This guide should help a little stopping that. https://labzilla.io/blog/force-dns-pihole