DNS Resolver (Unbound) is behaving inconsitently
-
Hi all,
I use some public DNS records with private IP addresses (i.e. host1.domain.tld > 10.10.0.1) and others on the same domain with public IPs. Now if I ping a host with public IP everything is fine (no surprise). Pinging a host with a private IP ends in
ping: unknown host host1.domain.tld
Which is - as I found out during the process - due to unbound sanitizing the DNS queries and blocking public hosts with private IPs. Which is fine as individual domains can be excluded from DNS rebinding protection (see https://doc.pfsense.org/index.php/DNS_Rebinding_Protections). So far so good.
What caused me quite a bit of headache is the fact that pfSense is behaving inconsistently depending from where a Ping is launched. Pinging a public hostname with private address from a computer in the LAN behind pfSense results in the error described above. Doing the same from the pfSense Webgui (Diagnostics > Ping) also from within the LAN works, aka returns the private IP address.
The expected behavior would be, that also Pings from the Webgui are handled in the same way as the one from a computer in the LAN and would not return a private address (unless an exception is added).I'm not sure if this should be considered a bug. If so, I would happily open an issue report.
-
"I use some public DNS records with private IP addresses (i.e. host1.domain.tld > 10.10.0.1)"
Completely and utterly BROKEN.. Do not do this!!! Unless your running some sort of spam filtering/dns blocking service where you return loopback for things??
It sure and the hell is not a bug, its a FEATURE.. Rebinding protection wouldn't even allow you to see the answer to these queries.
https://doc.pfsense.org/index.php/DNS_Rebinding_Protections
If you want your hosts on your network to get back rfc1918 for host1.domain.tld then create a host override and now all your clients will get back that entry when they query pfsense for dns.
-
In 2.3 how do you add exemptions to the "advanced box"? I can't find it on the system -> advanced page.
"Individual domains can be excluded from DNS rebinding protection using the Advanced box. Enter one domain per line in the following format, preceded by the "server:" line"
-
Just click the little button to show the box
But that would rarely be the best solution to rebinding protection.. Why would external dns have rfc1918 address in them? I could see if you were using pfsense internal to your network, downstream from your normal dns and were using dns of pfsense to query your internal domains. If that is the case you could prob just turn off rebinding protection all together.
Since your upstream server doing the external queries should have it on, etc. And if that was the case you prob better off just using the forwarder vs unbound as true resolver.
-
I was trying to follow the steps towards the bottom of this guide for setting up "Plex Secure Server Connections"
https://support.plex.tv/hc/en-us/articles/206225077-How-to-Use-Secure-Server-Connections
Similarly, if you happen to be using pfSense or a similar router OS, you may instead be using 'DNS Resolver (Unbound)'. If this is the case a similar advanced setting will need to be added:
server:
private-domain: "plex.direct"Thanks for pointing out that box. Turns out I was looking at the wrong page… Needed to be on Services -> DNS Resolver -> General Settings.
-
I don't get this problem… If your local to where your plex server is, why do you not just directly access the plex server IP or actual name on your network. Vs going through all that plex nonsense.
All my devices just access plex via actual name on my network, it is running on a box called storage.local.lan
-
Perhaps it is because we have different use cases in mind. Sounds like Plex is primarily used locally in your case. In my case I primarily use it remotely. I think on a different thread you mention that if you wanted to remotely access it you would just VPN in to access it. That is an option for me as well and I have done that in the past. However, I also use the library sharing feature on Plex with my friends and family. It is extremely convenient to direct my parents/parent-in-laws to https://plex.tv to see family photos/movies or other media on my server. I feel that asking them to use a vpn client would be more hassle than its worth. I appreciate your responses.
-
Hi johnpoz
Thanks for the reply. Unfortunately you may have misread my post or I have not explained myself well enough.
It is fine that unbound filters private addresses! What is NOT fine - and a bug in my opinion - is the following when a pinging a public host with private IP:
Situation A: Ping from a client behind pfSense LAN > no answer (This is the expected behavior)
Situation B: Ping from LAN within the Webgui of pfSense > the request is answered with private IP (this is NOT expected behavior)This is inconsistent. I would expect that also pings from the within the Webgui are filtered.
-
"Situation B: Ping from LAN within the Webgui of pfSense > the request is answered with private IP (this is NOT expected behavior)"
And what is pfsense using for dns? It can only do rebind protection if its using unbound, is pfsense pointing to 127.0.0.1 as its only dns? Post up screenshot of pfsense resolving this private IP from the gui, it should show what dns it used.
What do you mean ping from lan, and you get a query response - you mean a dns query, or you pinged something?
-
"Situation B: Ping from LAN within the Webgui of pfSense > the request is answered with private IP (this is NOT expected behavior)"
And what is pfsense using for dns? It can only do rebind protection if its using unbound, is pfsense pointing to 127.0.0.1 as its only dns? Post up screenshot of pfsense resolving this private IP from the gui, it should show what dns it used.
It's using the ISP DNS. But DNS resolver (unbound) is activated so everything passes through it first. At least the requests originating from a real client on the LAN network (situation A). For some reason (bug?) requests originating from the pfSense itself (situation B) are not passed through the DNS resolver first or at least not doing the DNS rebind checks correctly.
What do you mean ping from lan, and you get a query response - you mean a dns query, or you pinged something?
A ping to a public hostname. Therefore the DNS first resolves the name and the sends the ping to the IP returned. In situation A the error is host unknown, in situation B there is no error as an IP is returned.
I hope this clarifies it. I can post screenshots tomorrow if still necessary.
-
Well what do you show pfsense using for dns? If you have more than just 127.0.0.1 listed, then yeah it can ask them directly without using unbound to get our rebind protection
-
Well what do you show pfsense using for dns? If you have more than just 127.0.0.1 listed, then yeah it can ask them directly without using unbound to get our rebind protection
I have only the ISPs DNS server there. But that's not the issue!
All I'm saying is that pfSense is behaving differently depending from where the request originates. Please read my posts above again. I'll be glad to explain my observation again if it's not clear from what I wrote already.
-
"but that's not the issue!"
It is the freaking issue…
Dude pfsense isn't even using itself for dns, so no its not going to have rebind protection. Your only entry there should be 127.0.0.1 as I posted an example of mine. If a client asks pefsense, then yes rebind protection will happen.
I did read your posts - did you read mine where hosting rfc1918 in the publid dns is BROKEN out of the gate?
If you want consistent results then you need to be using the same dns...
You say unbound isn't consistent, but you have 1 client your actual clients using it, and then you have what pfsense does which you pointing to your ISP for dns.. So how does that have anything to do with unbound?
-
Dude pfsense isn't even using itself for dns, so no its not going to have rebind protection. Your only entry there should be 127.0.0.1 as I posted an example of mine. If a client asks pfsense, then yes rebind protection will happen.
Alright. I understand the reasons why it's the way it is. Let's leave it at that. The
I did read your posts - did you read mine where hosting rfc1918 in the publid dns is BROKEN out of the gate?
I certainly read your posts. And I also agree that private IPs on a public DNS is generally not a good idea. Still there are use cases where this might be required.
Thanks anyhow
-
All those use cases would be BROKEN ;) The only actual use case where public dns would not hand out public IP is you were using dns as a block list, so for example you hand out bad info for a site that you don't want to go to. Like a spam list, where domains MX are returned as 127 something.. Telling the client - that is BAD don't use it!
Public dns is for the public to use.. You putting in some rfc1918 address for a public name does not work for public. So if your plan is for it not to work like a blacklist then ok. But if your idea is for someone to resolve that rfc1918 and actually get to it then no its broken idea.
Your stuff that needs to resolve some fqdn to a rfc1918 address should be using a name server that is not public and hosts these records for your network to resolve, be it local, vpn road warrior, etc. Putting records in the public just for your clients to use is broken!
If you want your clients and pfsense to resolve the same thing, then they need to point to the same name servers..
What is your use case for these rfc1918 address, and be happy to discuss how your clients can resolve it without having to put it in public dns. Validation that rfc1918 in public space is broken is the whole point of rebinding protection ;) If your solution to some problem is putting rfc1918 in your public domain, what I suggest you do is re-evaluate what your problem actually is and find an actual solution that does not require some public dns server to resolve a FQDN its authoritative for to rfc1918.