Another Pi-hole DNS redirect question.

Witchboard

Hello. I've created the DNS redirect as the documentation instructs here.

https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

I've also searched the forums, and I think it's working correctly. I can perform a nslookup on my system and use a junk IP and it returns a domain.

I can run a nslookup using Cloudflare IP and I get a return.

I can run a nslookup using just my default DNS (Pi-hole).

But I would have expected it to return a local name if it was actually redirecting to my local DNS.

It works using default DNS.

But it's not working with either a junk or or Cloudflare DNS IP.

Is this working as designed or did I miss something? More importantly, is DNS requests still leaking outside my local network?

viragomann

@Witchboard
The client is requesting say 1.1.1.1, but you have redirected any DNS requests to pfSense itself.
So DNS Resolver on pfSense gets it and respond to it, then pfSense is sending out the response packet with the source IP 1.1.1.1 according to its state table.

So the client doesn't notice, that in fact pfSense was responding.

You can verify this by sniffing to the traffic on the internal interface, and also on WAN to get sure, that nothing is sent out.

If you still have any doubts, you can additionally add a quick floating block rule for direction out (but could also be any) for port 53 TCP/UDP to the WAN.

johnpoz

@Witchboard as @viragomann mentions - when you redirect to some other NS and what the client will see as the IP from the NS.. This NS you redirect to needs to be on a different network than the client.. Or the client might balk at the answer coming from a different IP.

The redirection instructions for pfsense are sending it to pfsense via loopback, ie 127.0.0.1, so to the client the answer seems to come back from where they asked, ie 1.2.3.4

I have gone over this multiple times in multiple threads where if you want to redirect to say pihole, pihole should sit on a different network/vlan than where your client sits.

here is old thread talking about the same thing

https://forum.netgate.com/topic/139457/transparently-intercept-and-redirect-dns-traffic-to-an-internal-dns

AndyRH

@johnpoz said in Another Pi-hole DNS redirect question.:

pihole should sit on a different network/vlan than where your client sits.

My solution does not require the PiHole (DNS) to be on a separate network. My notes show that is does work on the same network.

https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server?_=1663853296484

johnpoz

@AndyRH going to depend if you source nat, or if the client is smart enough to figure out hey.. Why when I send dns to 8.8.8.8 does the answer come from 192.168.1.100

This topic has been gone over multiple times.. There different ways to skin the cat.. But if you redirect traffic to 1.2.3.4 and the answer to the client comes back from 192.168.1.100 - any sane client would say hey wait a minute here.

If the ns your redirect to is on the same network as the client, but you source nat the traffic you redirect to your NS looks like it came from pfsense IP, then the NS would send its answer back to pfsense and pfsense would send that to the client - and the client wouldn't know any better.

The instructions for dns redirection are to pfsense loopback address, if your going to send the traffic elsewhere - you should understand the implications that might come with that if you want to make it work.

viragomann

@johnpoz said in Another Pi-hole DNS redirect question.:

if you want to redirect to say pihole, pihole should sit on a different network/vlan than where your client sits.

Oh yeah. This might be an issue here.
Since he posted to doc link, where DNS is redirected to localhost, I was only focused on this and didn't remember the pihole in the topic.

Witchboard

Hello. Yes, I've seen several topics on the same issue and understand it's like beating a dead horse. I do not have a managed switch, so I'm unable to leverage VLANs. I thought the loopback address would suffice, but I guess not. It seems to be working since I can request a nslookup from a nonsense IP and it resolves, but I understand it's not optimal.

I run unbound on my Pi-hole and use it as a recursive DNS server. The Pi-hole is also my DHCP server on my network. I've configured DNS resolver in pfSense to forward queries to PiHole as well as told pfSense to use remote DNS servers and to ignore local DNS so there's only the Pi-hole IP listed.

Not sure if this changes anything, but it's how it's all configured. Until I'm able to configure VLANs, I may just have to deal with what I got.

johnpoz

@Witchboard if you forward to loopback ie 127.0.0.1 and pfsense asks the pihole, which then forwards to where you want to forward your issues is not related to the address answering the client is not what the client sent the query too.

But you have to make sure that pihole doesn't get redirected back to itself.

You understand your legion isn't fully qualified.. The client would have to be adding the search suffix for that to work.

Try your test with the fqdn legion.lan.local???

Also .local is horrible choice for a tld, that is mdns... I would suggest you move to the currently recommended local domain home.arpa vs trying to use .local... This never a good choice for your actual domain, since that is the tld used by mdns..

https://en.wikipedia.org/wiki/.local

There are many NS that will not resolve those, since it should never really be asked for of a NS, since again its mdns

I would suggest you move your home domain to

https://www.rfc-editor.org/rfc/rfc8375.html
Special-Use Domain 'home.arpa.'

Or you could use .internal as your tld, this is suppose to be a new .tld to use for domains used only internally. Or change up your domain to be local.lan, I use to use that myself.. But have switched everything over to use home.arpa

Here I set pihole to answer for test.lan.local - notice the warning I get

;; WARNING: .local is reserved for Multicast DNS

$ dig @192.168.3.10 test.lan.local

; <<>> DiG 9.16.50 <<>> @192.168.3.10 test.lan.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62500
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test.lan.local.                        IN      A

;; ANSWER SECTION:
test.lan.local.         0       IN      A       10.11.12.13

;; Query time: 3 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)
;; WHEN: Thu Jun 20 12:36:02 Central Daylight Time 2024
;; MSG SIZE  rcvd: 59

Another possible issue could be if you redirect to loopback, and unbound fowards its traffic to somewhere, and the answer is rfc1918, that would be a rebind.. So if you have unbound set to foward to your pihole, and even if it answers like in my above example - unbound might not pass that back to the client because its a rebind. You would have to setup your local domain, lan.local to be a private domain.. And again lan.local is a bad choice to use for you local domain needs.

https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html#dns-rebinding-protections

Witchboard

Thank you @johnpoz.

I did try using the fqdn for legion, but it did not resolve.

I appreciate you pointing out my private domain is not good. I've corrected that. Should only take a couple of hours for it to clear up with the DHCP renewals.

I was using a Windows machine when performing the nslookups, so the error was not visible. I didn't get the warning you are referring to in your dig. Legion is a test CentOS box I've been playing with. I'll start using that for testing rather than my PC.

I used the below documentation for deploying my DNS resolver on Pi-hole. I'm not expecting you to read it, just putting it here for reference.
https://docs.pi-hole.net/guides/dns/unbound/

To be honest, I'm mostly ignorant about this stuff, but I can follow directions, even though I may not know exactly what I'm doing. I'll review the rebinding protections document you linked to.

I did create a port forward rule in pfSense to allow the Pi-hole to access external DNS servers, so I don't think it's in a loop. I can nslookup from the Pi-hole using Cloudflare for example, but it fails on a garbage IP as I would expect.