pfSense as a private DNS resolver
-
Hi,
According to the docs "By default, the DNS Resolver queries the root DNS servers directly".
So I disabled forwarding mode in the resolver, disabled DNS server override, cleared the DNS cache and performed a DNS leak test. The result was my real IP. With pfSense being the resolver itself maybe that's what I should see, but how can I know for sure that my ISP's DNS is not being used? How can I know for sure that the only thing happens behind the scenes is my pfSense querying the root servers? Is there any way to see the exact routes?
Edit: I just saw a post on this forum where @johnpoz answered this on a similar question: "if your using unbound as resolver, then yeah its going to show your IP. Since its resolving not forwarding."
So, if pfSense acts as the resolver and it asks the root servers (obviously it knows their IPs lol) I should see my real IP in the DNS leak tests, right?
Thank you,
-
Yes when you resolve you walk down from roots, so yes the IP you use to talk to the nameservers is what is "leaked"..
Unbound asks roots hey roots what is NS of .com
Hey NS of .com, what is the NS of domain.com
Hey NS of domain.com what is the IP of host.domain.comIf you want to see how it works, do a simple dig whatever +trace..
Here example, I made sure to only use IPv4 and had it not return any dnssec info so its cleaner to look at..
[2.4.4-RELEASE][admin@sg4860.local.lan]/: dig -4 www.pfsense.org +trace +nodnssec ; <<>> DiG 9.12.2-P1 <<>> -4 www.pfsense.org +trace +nodnssec ;; global options: +cmd . 60706 IN NS e.root-servers.net. . 60706 IN NS h.root-servers.net. . 60706 IN NS l.root-servers.net. . 60706 IN NS i.root-servers.net. . 60706 IN NS a.root-servers.net. . 60706 IN NS d.root-servers.net. . 60706 IN NS c.root-servers.net. . 60706 IN NS b.root-servers.net. . 60706 IN NS j.root-servers.net. . 60706 IN NS k.root-servers.net. . 60706 IN NS g.root-servers.net. . 60706 IN NS m.root-servers.net. . 60706 IN NS f.root-servers.net. ;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS d0.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS a0.org.afilias-nst.info. ;; Received 474 bytes from 192.33.4.12#53(c.root-servers.net) in 11 ms pfsense.org. 86400 IN NS ns1.netgate.com. pfsense.org. 86400 IN NS ns2.netgate.com. ;; Received 91 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 44 ms www.pfsense.org. 300 IN A 208.123.73.69 pfsense.org. 300 IN NS ns1.netgate.com. pfsense.org. 300 IN NS ns2.netgate.com. ;; Received 167 bytes from 162.208.119.38#53(ns2.netgate.com) in 34 ms [2.4.4-RELEASE][admin@sg4860.local.lan]/: -
@johnpoz Yeah...and this "leak" is basically the DNS leak test website asking to resolve a url and who ever resolves it for him is listed in the results. I had to think about for few moments and also do a test where I'm connected directly to my ISP's Modem/Router (bridge mode) and then the results were 10+ DNS servers belong to my ISP.
Thank you for the explanation nonetheless :)
-
Keep in mind that while on a new resolve unbound will walk down from roots, but once stuff is cached it will not have to walk down the whole tree again.
Once it caches say the NS for domain.tld, when you ask for something.domain.tld it will talk directly too one of the NS listed for that domain, it will not have to ask walk down to find the authoritative NS for domain.tld
Same goes for the tld nameservers - once it has those cached, it will just ask one of the NS for say .org, hey what is the nameserver for something.org
It also keeps track at which NS respond faster for a specific domain/tld - and will try and talk to those first, etc. You can look into that by directly asking unbound for that info..
unbound-control -c /var/unbound/unbound.conf
What you can do with that is listed here
https://nlnetlabs.nl/documentation/unbound/unbound-control/ -
@johnpoz said in pfSense as a private DNS resolver:
Keep in mind that while on a new resolve unbound will walk down from roots, but once stuff is cached it will not have to walk down the whole tree again.
Yeah, I knew that.
@johnpoz said in pfSense as a private DNS resolver:
It also keeps track at which NS respond faster for a specific domain/tld - and will try and talk to those first
Sweet...That's the spirit lol. I asked exactly that on a different post but received only lazy condescending answers from people with 10x my experience in networking...well...what can you do haha
@johnpoz said in pfSense as a private DNS resolver:
ou can look into that by directly asking unbound for that info..
Ask it via the unbound control?
-
Yeah you can query unbound for information about what it is in its cache, what it would use to lookup whatever.domain.tld, etc. etc.. Look over the documentation of unbound-control for what info you can gleen and stuff you can do with it, etc.
[2.4.4-RELEASE][admin@sg4860.local.lan]/: unbound-control -c /var/unbound/unbound.conf status version: 1.9.1 verbosity: 1 threads: 4 modules: 2 [ validator iterator ] uptime: 466951 seconds options: control(ssl) unbound (pid 30791) is running... [2.4.4-RELEASE][admin@sg4860.local.lan]/: -
@johnpoz I would like to ask you another question if you may.
If I have a default "allow LAN to any" rule with a VPN set as its gateway (NO_WAN_EGRESS) and I know your opinion about VPN and security paranoia lol but still...What would be the behavior when DNS requests are sent from this LAN to the pfSense? Would this rule make the resolver communicate with the root servers via the VPN gateway like the rest of the traffic, OR would the resolver has its "own channel" for that, apart from the rest of traffic generated by the LAN?Thanks,
-
Unbound would generate its own traffic.. This is traffic from "pfsense" not from the client.. Your lan rules have zero to do with what unbound/pfsense can do. your lan rules would just prevent client from talking to unbound in the first place - if your policy routing traffic out a vpn, your lan client wouldn't even be able to talk to unbound in the first place. Unless you had a rule above the policy route to allow it.
Client asks unbound for something, unbound either returns it from its cache or resolves it. If it needs to resolve it - then it makes its own connection for that through how pfsense is setup to connect.
Limiting or controlling pfsense or unbound to only use a vpn connection is difficult, your best bet if you insist on resolving through a vpn is to place your resolver inside your network, and then policy route it just like you would any other client.
There is a hidden rule, high up in the list that allows pfsense to go anywhere it wants..
pfctl -sr
pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself" -
Please bear with me haha I promise to learn quick :)
@johnpoz said in pfSense as a private DNS resolver:if your policy routing traffic out a vpn, your lan client wouldn't even be able to talk to unbound in the first place
But it's currently the setup I'm testing and it's using unbound with no problem at all...what am I missing?
@johnpoz said in pfSense as a private DNS resolver:
Unless you had a rule above the policy route to allow it
How to regard the unbound in this rule? What would be the source/destination?
@johnpoz said in pfSense as a private DNS resolver:
place your resolver inside your network
Do you mean a separate physical device used only for DNS tasks?
@johnpoz said in pfSense as a private DNS resolver:
There is a hidden rule, high up in the list that allows pfsense to go anywhere it wants..
Ok...I don't wanna mess with that functionality. DNS over the VPN gateway is not a must but at least I want the resolver to use DoT or any other encryption (stick it to the ISP) when it communicates with the root/tld/ns servers. Any idea?
-
What are the rules on your lan? Or floating?
If you want unbound to use dot, then set it to use dot.. But you can not resolve doing that - only forward.
-
@johnpoz said in pfSense as a private DNS resolver:
What are the rules on your lan? Or floating?
1 floating rule: NO_WAN_EGRESS
These are the LAN rules at the moment:
@johnpoz said in pfSense as a private DNS resolver:
then set it to use dot.. But you can not resolve doing that
So resolving the way pfSense intended will always be "clean" and unencrypted requests to the root servers?
-
Blocking bogon on your local network is just freaking pointless!!! In what scenario would you have bogon's on your network? And your rule for lan net would only allow lan net anyway..
Do you have any floating rules - because in those rules you are not allowing clients to talk to pfsense IP other than on ports 443 and 80.. So no you wouldn't be able to talk to unbound on 53.
If you setup forwarding, it will not resolve... You can not do both..
-
@johnpoz said in pfSense as a private DNS resolver:
Blocking bogon on your local network is just freaking pointless!!! In what scenario would you have bogon's on your network?
Don't know lol I'm quite new to networking and especially pfSense. It had the option to choose a harmless and at the same time maybe pointless blocking rule so I did...Indeed, it made much more sense on the WAN interface haha
@johnpoz said in pfSense as a private DNS resolver:
Do you have any floating rules
@johnpoz said in pfSense as a private DNS resolver:
So no you wouldn't be able to talk to unbound on 53.
If you setup forwarding, it will not resolve... You can not do both..I'm sorry but I don't understand. It worked just fine when I enabled forwarding mode and is working just fine now when it's set as a "pure" resolver...
-
My bad, you wouldn't be able to talk to other local networks if you policy route, but your any any rule with gateway like that would allow you to talk to pfsense IPs.. Since it doesn't need to route them anywhere..
Not clean doing it that way, if your going to policy route I like to explicit allow what you want and deny what you don't - and then route everything else out the gateway that your going to allow.
The not able to talk to other vlans comes up all the time when users policy route.
The rules say allow any any, if need to route it send it out X... Well it doesn't need to "route" to get there - so its allowed to talk to pfsense IPs with such a rule.
-
@johnpoz said in pfSense as a private DNS resolver:
The not able to talk to other vlans comes up all the time when users policy route.
Yeah...I forgot that VPN isolates you in a virtual local network of its own. Perhaps I'll separate it into more than one rule. Thanks.
So, what's the conclusion about DNS requests? Either use a separate resolver located inside/behind the network or except the way pfSense does it?
-
If your routing pfsense traffic out your vpn, then unbound would use that.. What happens when the vpn fails not sure.. But if you have unbound only bound to the vpn interfaces that will sure fail.. But can also cause issues when pfsense is booting and vpn is not up yet and unbound tries to bind to the interface, etc. Why you normally just bind unbound to the loopback.
If you want to be in complete control and sure that dns is never going to do anything other than go out your vpn, then put it on your local network and policy route.
If your going to use dot, doesn't matter how unbound gets to the internet - its always going to be encrypted..
-
@johnpoz said in pfSense as a private DNS resolver:
What happens when the vpn fails not sure.. But if you have unbound only bound to the vpn interfaces that will sure fail.. But can also cause issues when pfsense is booting and vpn is not up yet and unbound tries to bind to the interface, etc. Why you normally just bind unbound to the loopback
That won't be a problem. I set the Outgoing Network Interfaces in the resolver to be just Localhost as you suggested before. Also, set the WAN to be the default gateway so pfSense will use it for its internal needs etc. without any consideration to the VPN (up or down). When VPN fails, only interfaces that should use it, should be affected.
@johnpoz said in pfSense as a private DNS resolver:
then put it on your local network and policy route
- Are you talking about a seperate physical device for DNS resolving?
@johnpoz said in pfSense as a private DNS resolver:
If your going to use dot, doesn't matter how unbound gets to the internet - its always going to be encrypted
- I'm sorry but now I'm a bit confused. You said before that unbound won't be able to resolve using DoT, so you're talking here about forwarding to an external DNS (like Cloudflare) and use DoT?
@johnpoz said in pfSense as a private DNS resolver:
If your routing pfsense traffic out your vpn, then unbound would use that
- That's exactly what I want. DNS requests coming from X interface should be encrypted via DoT or simply go through the VPN gateway or even both lol. I don't care about the rest...let pfSense do its thing.
So can I be 100% sure that for DNS requests coming from the LAN net, the unbound will also go through the VPN gateway just like the rest of the traffic originated from LAN net?
EDIT: Sorry, I think I misunderstood you. By pfSense traffic you mean the entire thing using the VPN as opposed to just certain interfaces?
