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):
the PS4 DNS lookup fails:
and the PS4 says: Cannot connect to the server.
Solving your problem, update one PS4 and not the other, while both devices use a single pihole is simple:
- add the PS4 you want to allow updating to the default group.
- create a new group noPS4firmware
- add the PS4 you want to protect (no updates) to that group
- create the wildcard entry (see above) and assign it to the noPS4firmware group
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
1 Like
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
- pihole checkout ftl new/regex_replytype
don't like it, or something doesn't work?
- report the problem
- pihole checkout ftl master
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...
1 Like
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.
1 Like
Good enough for me. Actually, if you get lucky, you could also define REPLY_ADDR6 and maybe get two uses out of it 
Yeah, this definitely still feels like a workaround, but is a huge improvement in its current state, because it fulfills most of the points in the OP: I haven't actually tested this on my devices yet (I'd rather do that at night because otherwise my family is gonna complain if something breaks), but this looks very promising. I'm just worried that once I mark this as solved, it means that this will never get implemented "properly", because "it kinda already works".
I'm not going to argue about this - it is a workaround. However, since I don't really see redirects coming any time soon, it is a well-working workaround. I'm not looking forward to such a feature because of aforementioned HTTPS issues. At some point, plain HTTP queries will be gone and this feature would (a) turn pretty useless and (b) cause a lot of questions (i.e. support workload) in the style of "why does this not work as expected".
Feature pull request:
Okay, so after throughly testing this, I must say that I'm pretty happy with how it turned out. I've marked Custom Redirects - #31 by jpgpi250 as the solution, but of course all credit goes to @DL6ER. So thank you!
Three notes:
- Since this all resides in the blacklist now, you have to make sure to put your redirects above your actual blocks (in case there are collisions). This actually got me while testing.
- I know this gets into "harm maintainability" territory but would it be possible to differentiate between
reply=ip4andreply=ip6? To be safe, I've setREPLY_ADDR6to::, but this could be avoided by not sending a IPv6 response at all. - Not really related to this, but somehow
http://<piholehostname>redirects toREPLY_ADDR4(if set) on my PS4;http://<piholehostname>.localworks though.
nslookup <piholehostname> <piholeip>
returns the correct result while
dig <piholehostname> @<piholeip>
returns the REPLY_ADDR4. The PS4 probably doesn't use the search domain? It has worked before though (or without the Pi-hole).
I'm not really sure what the cronjobs do exactly, but will they keep the branch up-to-date? Hopefully the code will find its way into master soon (hopefully in v5.9) 
I see that the way to achieve this through REPLY_ADDR{4,6} has too many possible disadvantages. Hence, I extended the extension furhter to also eat IP addresses directly, like
- IPv4 only:
myregex;reply=1.2.3.4
will result inA 1.2.3.4andAAAA :: - IPv6 only:
myregex;reply=fe80::1234
will result inA 0.0.0.0andAAAA fe80:1234 - IPv4 and IPv6:
myregex;reply=1.2.3.4;reply=fe80::1234
will result inA 1.2.3.4andAAAA fe80:1234
Please update and test!
No, you'll have to update manually. You also have to remember to switch back to master once the next release is out or you will stay on this (then abandoned) branch forever. You should get informed about available updates on a custom branch just as usual.
1 Like
I didn't ask for that, but I'm glad you did because this solves this request 100% now. I can finally remove every entry from my Local DNS now, which is great. This approach also avoids the weird http://<piholehostname> situation (tested and confirmed).
I'm pretty impressed how you've managed to integrate this so seamlessly, while still keeping it manage- and maintainable (hopefully). It was a clever approach and I couldn't complain even if I wanted to. Hats off to you, sir!
The only thing that's really missing is:
But that's gotta be the edge case of the edge case, so please don't waste your time on that 