Well, I can't seem to figure out how to do that with Pi-hole (it looks like I need DHCP?) but my current method consisting of Local DNS Records, blacklisting the regex and whitelisting the redirects works okayish. I'll just have to avoid Pi-hole on my second device; not a big deal.
Don't waste your energy trying to explain it to me because it looks very complicated and I'll probably won't understand it anyway, just please consider it for the future.
Today I randomly had another idea and even though it might not be terribly useful I wanna get it off my head: redirect domain to domain. So instead of just redirecting the host request to an IP address, Pi-hole would actually resolve the target domain and redirect the request domain to that.
That's what CNAME entries do.
Pihole will likely contain the ability to set those in a next version
It's been a while since I've looked into this, but I visit this one year old request from time to time to check for new comments. Is this still something that's considered too niche to implement? From my short research it looks like dnsmasq doesn't even understand RegEx to begin with (I found a fork which does though) and I'm not sure how to solve this on my own.
Anyway, even with the original goal of blocking ads, I can still see redirects as being useful. Sometimes you have Javascript which detects if an ad loads, so straight up blocking that with Pi-hole would only trigger their Anti-Adblock. If you instead redirect it to something else, something you control, you could theoretically trick their countermeasures.
Also, as I said in the OP, simple redirects are not exactly what I want. I'd like to combine them with other Pi-hole features, such as Group managment and RegEx matching. Local changes on the device in question are not possible, and I wouldn't want to redirect the requests for every device on my network, so I'm left with not using my Pi-hole network-wide because of that.
This feature request currently has zero votes.
Well yeah, but actually no. There are similar requests all over this forum (e.g. DNS redirect, URL redirection with Custom DNS, Blacklist : is it possible to redirect to a specific address?, ...), so it's unfair to say that it's just me that wants it. But I do understand that the team can't or won't focus on this at this time. See y'all next year 
Two of the three are not feature requests.
Short summary of what I think is what you are asking for: Configure only specific blacklist/regex entries to redirect to a custom IP address. So, basically, local DNS/CNAME records but device-specific (e.g., through group management). This should also allow you to specify multiple targets.
Is this correct? Did I miss something?
I don't think what you are suggesting will work for the sketched purpose because of HTTPS being used virtually everywhere. If you are not very very lucky and the service is plain boring HTTP without any authentication, it may work. However, if they are indeed contacting 01.eu.status.com no redirection will actually work because you will not be able to provide a valid SSL certificate for this domain. The success rate with self-signed certificates is dramatically decreasing because of the widespread use of certificate pinning.
No, because blacklist entries have no further details. The mere fact they are present on the list suffices to trigger a blocking. If we'd have to lookup the actual database record, this would be horribly slow (imagine huge blacklists) and may cause DNS resolution to cease on low-end devices.
This is one way, you can specify that device A uses Pi-hole A (which blocks to the wanted IP address) and device B uses Pi-hole B (which doesn't block). Or let device B use any other public DNS server. As you prefer.
Exactly.
I appreciate the advice (I've encountered this before already), but I think you got that wrong: These redirects are already in play. I've successfully redirected the domains and everything is working as intended. Right now, without having these Custom Redirects, I can't have the other Sony devices connected to my Pi-hole, as that would interfere with the normal operation. So it's either get two Pi-holes or don't use the Pi-hole network-wide for me.
Of course there are workarounds, but I'd prefer to do this properly.
I'm trying to generalize this idea from the niche it currently lives in to something that makes sense for more people and how to add it seamlessly into the Pi-hole universe.
I wonder, could this be a usecase for
where you can specify that a certain regex can be blocked by, e.g, an IP different than the blocking mode used everywhere else.
Well, just having device-specific redirects would already be a huge step-up and would allow me to use my Pi-hole for the whole network. Everything else, like the aforementioned RegExp support and the ability to create comments, would just be a bonus.
Regular expressions can already be managed by groups. By adding a modifier that'd allow you to say: But I want the reply to this regex be different than the default blocking mode, we could achieve exactly what you are looking for.
You once tried something similar (read here).
edit
I don't really see the point of presenting a customized IP, for a domain that matches a regex, as this will result in a certificate error most of the time...
If it's a requirement for a specific domain, the user can always use (dnsmasq):
-A, --address=/<domain>[/<domain>...]/[<ipaddr>]
In the original test, you attempted to reply with something that matched all possible blocking modes, e.g. 0.0.0.0 or ::, nodata, nxdomain, configured IP address (useless unless http). Given the recent changes you made here, I assume adding drop would be a nice adittion.
/edit
When a PS4 starts up, or the user goes to settings / system software update, this is the query executed:
By simply creating a blacklist entry (domain as wildcard):
Solving your problem, update one PS4 and not the other, while both devices use a single pihole is simple:
done, the PS4 you want protect (no firmware updates) will always try to resolve the domain, but will get an answer, depending on your blocking mode (probably 0.0.0.0).
all other devices, not member of the group (noPS4firmware) will succesfully resolve the domain (test with dig on any device / computer).
The regex improvements, made available by @DL6ER are a great and essential part of pihole, but it doesn't look like your PS4 update problem is a valid use case.
I don't think this is the same as
However, I also don't know if there is any downside to just blocking away the update requests (will there be errors or other undesirable behavior?). If blocking works equally well than mocking a "You're good" response, it is the better choice because easier and with less configuration effort.
true, the following (requires the regex improvement branche) will work. This ensures the answer is the IP address of the pihole.
dig result (IP modified, due to regex, so it works...):
; <<>> DiG 9.16.4 <<>> fuk01.ps4.update.playstation.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19237
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fuk01.ps4.update.playstation.net. IN A
;; ANSWER SECTION:
fuk01.ps4.update.playstation.net. 2 IN A 192.168.2.57
;; Query time: 4 msec
;; SERVER: 192.168.2.57#53(192.168.2.57)
;; WHEN: Fri Sep 10 09:55:10 Romance Daylight Time 2021
;; MSG SIZE rcvd: 77
when choosing (on the PS4) settings / the message now is 'an error has occured (CE-34459-5)'
looking at the wireshark output, after getting the address (received a modified address, due to pihole regex), the PS4 immediatlly starts making requests on port 443, which suggests a certificate error would be the result (my pi isn't configured to answer this incoming request, hence the invalid answer).
however, since the mission appears to be accomplished for pihole, the new branch, and thus pihole, does what it needs to do, e.g. reply as if the blocking mode is IP, even though it's really running on blockking mode null
It is now upto @Anuskuss to ensure the pihole replies with a valid answer to the PS4 request to make the circle complete.
edit
using (\.|^)ps4\.update\.playstation\.net$;reply=nodata, the error changes into 'A DNS error has occured (NW-31254-5)'
using (\.|^)ps4\.update\.playstation\.net$;reply=nxdomain, the error changes into 'A DNS error has occured (NW-31251-2)'
/edit
I knew it was a mistake to mention the PS4, because I knew that someone would just mansplain (I hate that word but it fits perfectly) to me. To reiterate: I have a working solution already, I just want to improve it. Please stop telling me how to do it differently, this is NOT about the PS4 but a general request.
Another use case I have is redirecting a website to restore some functionality on my PSP. And no, it's not HTTPS. Yes, I already have a redirect. No, I don't want to redirect it for every device in my network, ONLY for my PSP.
This sounds interesting, but I'm not comfortable to deploy a WIP branch on my network (not with that many other devices which depend on my Pi-hole). I'll make sure to check it out once it's released.
If nobody, even the requestor, is willing to test it, we will not be getting many improvements....
Testing this branch is as simple as
don't like it, or something doesn't work?
If you don't test features that will affect you in the future, you might get unexpected results when the feature is released, than, there is no easy way back...
playstation.com;reply=IP works and is what I'm looking for. Seems like arbitrary IP addresses are not yet implemented though? Just returns 0.0.0.0 right now.
I mean the place to set that up is a little weird (Blacklist instead of Local DNS), and the average users would have problems discovering that on their own (I consider myself the average user and I wouldn't have found it myself), but yeah, this is usable (minus the custom IP address which I use for one of my redirects).
Thanks for testing!
Yes, this is possible by setting
REPLY_ADDR4=192.168.x.y
(docs link), however, it supports only one IP address. That is because the redirection in this way is more an intended side-effect of regex blocking than a real implementation of redirections.
Now comes the usual disclaimer, but I'll say it anyway: Adding edge-case implementations will harm maintainability. Hence, before adding entirely new stuff that may block us from doing other things in the future (the audit feature did so a few times by now), I'd rather like to extend existing stuff. I know, it looks like this could be simple for Local DNS records, however, it'd need a complete reimplementation of the feature because Local DNS records currently live in a namespace that is not aware of groups at all.
If it is only one IP address that is needed, the current solution seems to be the best compromise. If more than one redirect is needed, I can imagine extending the syntax like
playstation.com;reply=192.168.5.9
so any valid IP address is takes as argument. This, however, would out additional storage constraints (incl. bookkeeping about 20 bytes more per entry) for both the list of regex and the DNS cache. Given that the DNS cache records are currently only 16 bytes, this is a significant change.