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.
Just go to PiHole's "Domains" page, in the box labelled Domain, type youtube.com, enable the checkbox for Add ___domain as wildcard, then click the button labelled Add to denied domains.
Now youtube.com and all of its subdomains are blocked, for all clients.
If you wish for it to only be blocked for some clients, then assign your clients to groups, and set the setting appropriately on the domains page.
I think you would need to explain your definition of 'best' here — I mean: explain why you think it is better.
> making regex blocks are appropriate.
I guess here you actually mean inappropriate?
Perhaps. But I think you misunderstand what I am doing, and how that then works in PiHole.
The method I describe, uses the Domains tab on the Domain Management page — and not the RegEx Filter tab.
The distinction is somewhat of importance, because the implementation of PiHole uses a different code path for exact-match denies/accepts, vs regex denies/accepts. (Type 0 and 1, vs type 2 and 3, detailed here[1]). Adding a ___domain the way I describe, creates an exact-match type entry in that table, not a regex match type.
But even if it were still using regex, the cost of that isn't as high as one might imagine, due to the fact that subsequent repeat queries to the same ___domain, do not get checked against regexes again: the result is cached.
As described here [2]: "Our implementation is light and fast as each ___domain is only checked once for a match. When you query google.com, it will be checked against your RegEx. Any subsequent query to the same ___domain will not be checked again until you restart pihole-FTL."
In summary: adding a ___domain the way I describe doesn't create a regex filter anyhow. But PiHole's regex matching isn't a naive implementation, it caches the results, so that it only actually performs the regex matching on first query to a ___domain not seen before (since last restart).
So really it makes no difference at all if one blocks a ___domain the way I describe, or the way you describe. They both end up doing the same thing: they insert an exact-match filter entry into the database.
In which case, it's simply down to one's own preference: do you prefer looking through the query log to find the site to block... or do you prefer just typing in a ___domain name.
> 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.
And if your gateway device is configurable enough you can ban or redirect port 53 requests (DNS) to whatever machine you would like to use to serve up resolution.
DNS doesn't have redirection like HTTP has, so what you describe can only be implemented using port forwarding (or SSH tunnelling, but I've never seen a router with the ability to tunnel DNS in this fashion?).
Port forwarding used like this, won't enable one to use the 'groups' functionality on PiHole — which was the (g)parent thread here — because all requests arriving at the PiHole will come from the same client, i.e. the router. Because port forwarding is more like a proxy than a redirect (to use HTTP terms).
The correct solution here if one wishes to use PiHole's groups — and not have a janky network configuration like you describe here (an extra unnecessary hop for local DNS) — is to either (a) use the router's DHCP settings to tell the clients to use the PiHole IP for their DNS, or (b) disable the router's DHCP and simply use the DHCP that PiHole provides, which is at least as good as what most routers provide (and more configurable than most routers also, should one need to)
Erm, it's not redirection, because, like I said: DNS has no redirection — not in the sense that HTTP does.
If you don't understand this, then you are perhaps lacking some knowledge as to how HTTP redirects work, and/or how DNS lookups work, and/or how they are quite different concepts.
HTTP has redirects. DNS doesn't - but sure, it can be intercepted / hijacked.
> It's that time again got to read the man page
No need for the snark, this is HN, not Reddit.
But I'm already well aware of the feature you describe (after all, PiHole/similar relies on exactly this kind of interception) — but it isn't actually new at all, dnsmasq has had this since the the very beginning, literally day one.
It's still not redirection like HTTP though, it's interception: serving an IP number from a conf file when a matching ___domain is requested instead of querying upstream. Very similar to adding an entry in your local hosts file.
Redirect isn't a term that is really ever used in DNS configuration. Except in the context of NXDOMAIN responses. And that's certainly not the topic of this thread.
With HTTP redirection, the server responds with 'moved' and the URL of the new ___location of the requested content. But all one can do with DNS requests, is to respond: this is the IP for the ___domain A/CNAME you requested (or respond no-such-___domain). In HTTP, that kind of inline interception can only be done with a proxy (transparent or otherwise) — and that's not the same as a the HTTP redirect mechanism at all.
Some folk might argue that this is only a semantic difference. But it's not at all: they're quite different mechanisms, different traffic-flow / communication patterns. And the distinction is quite important to anyone who manages both DNS and HTTP, at a certain level.
But if you want to call it DNS redirection, then good for you. But the old-timers will call it out nearly every time, because it's not actually redirection. — DNS doesn't have redirection like HTTP. Not in the same sense as HTTP at all. Anyone who claims otherwise, really just needs to brush up on their DNS knowledge / terminology.
> That doesn’t correct the situation in which the device is ignoring DHCP DNS requests.
That's the first time such a thing has been mentioned in this thread.
But I now get what you're trying to say in your comment above.
Sure, one can use e.g. iptables, to forward all outbound traffic on some port to some local IP. If your router has such capabilities.
But your rules won't be as simple as forward all port 53 traffic: you'll need to ensure that you exclude the PiHole from any rules like that (otherwise it would create an infinite loop) - or ensure the rule is specific for the device(s) in question.
And of course it wouldn't work if the device is using DoH.
But the issue you've introduced here, a device with hard-coded DNS, isn't really what this thread is about — the topic here was ~about wanting to group clients in PiHole, and different ways to configure the router to achieve this, without only seeing a single requesting client IP at the PiHole.
The question and assessment is around how your dhcp device can control DNS behavior (usually by broadcasting the name server IP). And I pointed out many devices that do DHCP often also act as the gateway device and internal firewall.
It’s not meant to answer your direct question, but pointing out what’s possible. Because yes, there are a lot of IoT and other devices that misbehave on a network.
And it’s incredibly trivial to port ban or port forward a selection of IPs and not affect the behavior of your Pi-hole. Packets carry last hop ip and source ip. I do it all the time on my gateway device.
DoH is a completely different story. Now you are talking about browser based DNS systems, apple private relay and other related 443 based solutions.
Yes. And that's why, in the context of misbehaving devices, carrying their own methods of doing DNS, I mentioned it.
> Now you are talking about browser based DNS systems, apple private relay and other related 443 based solutions.
No, not at all. Anything can use DoH. Doesn't need to be browser-based, nor using Apple private relay, nor anything of the kind. A device simply needs to be coded to make its DNS queries over HTTP. In a similar fashion to how it might have a hard-coded value for its DNS lookups, the developer can simply include a small library to do DoH instead. And that's not going to be so easily filterable by a rule for outgoing traffic / port forwarding.
I have all of my PiHole DNS lookups going over DoH. Have done for years now. Because when I originally setup my secure DNS, DoH was a better choice that DoT, because DoT was very much still in flux. And by comparison, DNS over an existing standardised transport is pretty much a known quantity. So that was my choice. And it works great.
So all of my network's DNS lookup go out over DoH... there's lots of DNS providers that provide DoH nowadays, including plenty of very big providers. My secure DNS proxy cycles between different servers.
DoH functionality is even just built-in to Bind these days.
In reality, DoH isn't in any way restricted just to the services you describe here. Far from it. It can be used anywhere. It's just a protocol. With plenty of destination endpoint support, out there in the real-world.
And if some device wants to control its DNS to that kind of level, then, beyond simply having a hard-coded DNS server value, using DoH is pretty easy.
No browsers needed, no Apple Private Relay needed.
There's no extra cost for extra domains, on everything but their smallest account — and as we already have an account for all of our other domains, using Migadu for side projects as well is a no-brainer.
This has been my goto React UI framework for a number of years now - and has helped me deliver a number of projects, ranging in size from big to small. It’s consistent, well thought out, and both clients and users like it.
I've not evaluated either of those two in the past, no. Neither of them existed last time I looked for decent competitors to Ant Design's library.
Hmm. When I go to the MUI website right now — e.g. https://mui.com/x/react-data-grid/ — and then click the hamburger menu, top-left, the resulting menu just goes nuts, glitching and toggling on and off, non-stop (Safari 17.5, on macOS Monterey). So I am unable to even look at MUI properly currently. So, quite honestly, that's the end of any further evaluation there for now. Arguably: it doesn't bode too well, but maybe they're just having a bad day? (I notice that Ant's website is totally down currently also, which I've not seen in a very long time — perhaps it's had- or they have both had- the HN hug of death?)
— But TBH, based upon what I've just read on their site: MUI isn't really going to be an option for us, because of its commercial licensing.
But their stuff might be worthy of consideration / buying a license, if their stuff totally wowed me — but the bar is set quite high with Ant, which has a lot of components, with a lot of functionality, and is fully open-sourced (and backed by some big companies, and with years of development behind it already). Their table (data grid) looks ok, but a bunch of the features (which Ant has) are commercial-only.
A quick look at Chakra shows that doesn't have a date picker, nor a calendar, and their table is nothing more than a nicely styled basic HTML table — no additional functionality — no sorters, no pagination, no filters, no row selection, no fixed-columns, all of which, and more, Ant's table already has — Granted it can likely be coupled with the likes of TanStack Table to add some of these, but that's just more work when one just wants something that just works straight out-of-the box (and TanStack Table still doesn't cover everything that Ant does).
Ant Design also has a good handful of other quite useful components, that I don't see in Chakra — Chakra seems to have about half the amount of components?
In short, to me, Chakra seems a bit too new / immature — or perhaps simply has a smaller scope? — when compared with the likes of Ant Design's React component library — which, for desktop apps, is certainly much closer to being 'enterprise grade', straight out-of-the-box, with no messing about (e.g. with third-party components, perhaps less well maintained).
It looks promising though — but I've looked at plenty of other UI libraries over the years that looked promising in their early days, but never grew particularly much, so we'll have to wait and see. But right now, it's some way from being usable on much of the stuff that I build.
I've only ever used MUI, myself, and was curious to know what others thought of similar projects. Sounds like Ant is truly FOSS and more powerful in some ways.
No need to keep Mojave to run iTunes — iTunes can be run on newer macOS, by using Retroactive [1] to patch it.
Regarding running a newer macOS on older hardware, check out OCLP [1] — do make sure you make full backups and have a working recovery plan before trying anything with OCLP though. I know that might sound somewhat obvious to a lot of folk, but you'd be surprised at the amount of folk that jump in and try OCLP on their main system without any backup plan.
Note that are some gotchas re installing OCLP on some older h/w, and it will help to read up on possible issues before wading in. e.g. during installation it might be necessary to use a wired keyboard and mouse, via a USB hub, until the installation is done, you might also need a wired network connection during install, similarly. Depends on h/w (I've not patched MacBooks myself, yet). Once the patcher is done, these should not be needed anymore.
Official support for OCLP is only via Discord — but there is a very active unofficial peer/user support group on FB [3]
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.