Pi-hole v6

> What's more likely though is that you just point your router's DNS setting to Pi-hole, and in that case there is only one client on the Pi-hole dashboard - your router.

That depends entirely on what capabilities your router has.

Many routers have a setting for the DNS info they give to clients via DHCP, which would mean every client is indeed using PiHole directly for DNS resolution.

Other less capable routers, only have a setting for which upstream DNS server(s) the router should use, which of course isn't going to allow you to do anything with PiHole's group stuff.

But an easy solution is simply to disable the DHCP server on the router, and simply use what is built-in to PiHole. It uses dnsmasq behind the scenes, and as DHCP servers go, it's pretty capable and configurable. This is how I use PiHole on my own network, and have done for years now (with some customised dnsmasq config, because I have strong preferences about my network setup and services).

Most routers do nothing particularly special regarding DHCP anyhow, so no big deal to just turn it off, and use PiHole's stuff.

FWIW, and tangent to these specific points, my upgrade to the new PiHole 6 earlier today was pretty smooth — with the exception of it defaulting to having its dashboard on port 8080 instead of my previous 80. Plus I had to tweak a couple of settings to ensure it loads my custom dnsmasq config. But no deal breakers at all.

The better option is to configure DHCP to hand out the Pi-hole as your DNS server. If your router cannot do that, but you want to go deep enough to configure your home network with a Pi-hole, you should probably also invest in either a better router or OpenWRT on your current one to get a few more features.

Ideally, you do not run DNS on your router at all, and you also block outbound to 0.0.0.0:53 from anything _except_ the Pi-hole, so that there's no convenient way to get to an unblocked DNS by bypassing it.

DNS-over-HTTP is a bit harder to block, and of course malware could have an IP baked in and so bypass this entirely.

It works for me and I don't use Pi-Hole as a DHCP server or have any of my devices individually configured. I have my router acting as a DHCP server and have it tell clients to use my Pi-hole for DNS. Some routers' default firmwares don't let you do this, but most OpenWRT and Tomato and the like should.

Using clients and groups works fine for me. I'm able to block youtube on my kids' devices, but allow it on others. I have pihole running in a container without being my dhcp server.

That's my only gripe with the current pi-hole; there is no easy way to configure DHCP options.

Not all routers proxy DNS; many have DHCP settings so you can give the pi-hole’s address as DNS server to clients via DHCP.

I imagine this is how it’s usually done. There’s no reason to double proxy.

Previously, PiHole used /etc/dnsmasq.d/ with best practice being to put one's own additional config, or overrides, in separate file(s) in that folder.

PiHole v6 appears to have most of that config built-in, and upgrading to v6 removes all of the previous standard config files, leaving only user-created / user-edited files in /etc/dnsmasq.d/ - and PiHole v6 by default no longer imports anything from this folder (to prevent possible incompatibilities).

But it's just a setting, and toggling it brings back the original functionality of importing config from files in that folder. And for me, my custom dnsmasq config worked just the same as it previously did.

> Really weird, because there's less stuff in it.

It's also not subsidized by selling your user data.

> Really weird

No, not weird. The extra stuff is there to show you ads and/or track your behavior, which generates a stream of revenue for the TV maker. W/o the extra stuff, the only revenue comes from the one-time purchase.

Is there an equivalent of DDWRT/OpenWRT but for TVs?

Most often those are some embedded linux board running some Android fork, shouldn't there be some TV models on the market that are a good hardware/price deal with firmware that can be replaced?

Even something that just permanently shows HDMI input with no popup overlays would be good, but AOSP + VLC/Jellyfin would be even nicer.

Or more likely: reduced privacy settings, increased analytics, and in-menu advertisements.

Why would the manyfacturer spend money on that if it had your sale already and you aren't paying any support subscription?

Yes, those are the "smart" features. Just plug in a Raspberry Pi and don't touch the TV after its initial setup. I'm still using the same Raspberry Pi 2 I've been using for more than 5 years now. Beats "smart" TVs that you can buy today.

I let one of my cheap smart TVs update for this reason (and not the other two identical ones I have) and now that one crashes and lags all the time, despite none of them being on the internet.

Embedded device software development quality is usually even worse than webapp software development quality.

Call me pessimistic, but as the sidewalk pattern becomes more common for IoT, I wouldn’t be surprised if a “malfunctioning radio” just results in the device not working properly.

Smart TV opt-out telemetry is malicious.

Running w/ my opnsense router. All-in-one.

[dead]

Only if they're configured to explode if not pinged for 30s or something.

The only times I have seen this happen is when the remote devices were communicating with something on blacklist (which should be concerning anyway, but also a quick fix if not) or doing something naughty like not using the DNS server broadcast by DHCP.

Hmmm, my router caches DNS queries.

You can just run something like dnsmasq locally though.

You can run NextDNS on your router to solve this.

I think my PiHole is up for 3+ years on a Raspberry Pi dedicated to that task. Did not fail once since then, so not sure if "DNS is going down" is really an issue. But maybe I've got survivorship bias.

DNS issues during power outages is the least of your problems, as chances are your Internet and all your PCs are down as well.

But you don’t have to run pi-hole on a pi. I run it in an Ubuntu Linux container on my Proxmox server.

I run AdGuard Home on the same device as my router, so anything that would take it down would also take down the entire router anyway.

> Yes because you judge people by the country they live in.

This is an extremely uncharitable reading of the preceding comment. The comment is clearly concerned about the national jurisdiction from which the AdGuard binary originates, not the national origin of a human.

American government initiatives against Huawei telecom hardware at critical junctures aren't making a personal statement about Chinese individuals. European regulatory skepticism of American-located cloud services isn't a personal statement about American individuals. Russia and China requiring the on-shoring of data-centers doing business in their internal economies aren't making personal statements about foreigners by doing so.

Whether or not you hold all those governments as roughly equal, none of them mistrusting each others' jurisdictions is "judging people by the country they live in." It is judging the trustworthiness of the governments of those countries. And the people in those countries are inevitably subject to the jurisdictions of the governments that rule them.

If someone actually attacks people on the basis of national origin, have at it, but please don't brow beat individuals for making common-sense risk assessments.

I actually didn't know this. Thanks!

I don't trust Iran, North Korea, or China either. It's not hard, I'm an American and it's 2025. These are our adversaries (I didn't choose them) who currently commit cybercrimes against us. Hopefully in 2035 that won't be the case and we can all sing kumbaya.

Opnsense is not like OpenWRT, it targets running on relatively powerful generic x86 hardware. Intel CPUs and networking hardware usually works best because of driver support on BSD, but it will work on others. I say "relatively" because even low power old embedded CPUs are more than enough to route at a gigabit or more with lots of firewall rules and services running. Opnsense's cousin Pfsense also has some support for ARM, but that version is only really available on their commercially supported hardware.

Most people either buy a generic box that can be had for ~$250, or recycle an old PC and stick in a network card. You can also buy commercially supported hardware for Opnsense or Pfsense's parent companies, though the value proposition isn't worth it for home users IMO as you will pay a steep premium versus loading up something yourself.

I bought my router from this site: https://teklager.se/en/products/routers/

They have some guides and stuff that explains the hardware requirements that might be helpful for you.

Pihole catches a lot of the trackers and crap coming out of my android tv. On my pc I see it as an extra line of defense after ublock.

You can't use uBlock everywhere, .e.g phones, tablets, TVs.

However you can't use it on the phone while not at home (aside from using vpn/wireguard), but nextdns allows it.

As for the latency - is it really noticeable?

Define latency ?

This is my latency (ping.nextdns.io):

  zepto-cph (IPv6)    12 ms  (anycast1, ultralow2)

  zepto-cph           13 ms  (anycast1, ultralow2)

  anexia-cph (IPv6)   15 ms  (anycast2, ultralow1)

That’s a good point, assuming your router allows you to do that.

ATT apparently removed overriding the DNS for IPv4 and IPv6. I had to double check because I thought I could do IPv4 but no.

There’s supposedly several options around it to use your own router but it’s not really worth setting up and my speed is slower using a second router.

Right! When my Pi died, my network didn't look for a backup DNS, so everything became inaccessible. It was weird - probably the classic SD card issue. With NextDNS, while I do use DNS over TLS, if my Synology fails, it just kicks back to regular NextDNS domain name servers.

They do let you switch it off, it's just a bit buggy sometimes (like having to toggle twice), I know because I use it all the time. https://i.imgur.com/YpSkS93.png

I use Tailscale as my primary interface for handling this. Simple as adding your nextdns id number in the DNS settings and you are done.

Instruct your Tailscale invitees to download the app and voila, simply toggle it on or off as needed.

DoT has a standard port, meaning blocking (conforming) requests simple. DoH uses 443.

Nothing says clients need to confirm to the port requirements, but most companies will be lazy and assume 853 will work.

DoT sure. The whole “tunnel everything over http” is a terrible pattern