Cloudflare + BIND9 + pfSense DNS over TLS
-
@FragRot said in Cloudflare + BIND9 + pfSense DNS over TLS:
My goal is to be able to connect to existing DNS server using DNS over TLS via my domain.
So you want to talk to your bind server via dot, did you set it up? So your bind is just a NS and cloudflare is the soa for your domain?
You understand dot is to talk to a recursive server right - its not to talk to an authoritative NS for domainX.tld
edit: also dot is not really a client protocol, clients talking to a NS for recursive would normally use doh.. Dot is more for a NS in forwarder mode to forward to some other NS..
Not saying their are not dot clients out there, but doh is what is normally used.. What exactly are you wanting to accomplish? I setup unbound on pfsense to listen for doh and dot..
-
@johnpoz said in Cloudflare + BIND9 + pfSense DNS over TLS:
@FragRot said in Cloudflare + BIND9 + pfSense DNS over TLS:
My goal is to be able to connect to existing DNS server using DNS over TLS via my domain.
So you want to talk to your bind server via dot, did you set it up? So your bind is just a NS and cloudflare is the soa for your domain?
You understand dot is to talk to a recursive server right - its not to talk to an authoritative NS for domainX.tld
edit: also dot is not really a client protocol, clients talking to a NS for recursive would normally use doh.. Dot is more for a NS in forwarder mode to forward to some other NS..
Yes I have set-up DoT using NGINX. I do understand that. It's supposed to talk to existing DNS server which is of course recursive. I'm trying to use my domain which is x.x.com as my domain to be able to use DoT. For example, on Android I would set x.x.com as my private DNS do achieve DoT.
-
@FragRot so you have setup and doing a directed query not working with nginx as your offloader, I would suggest you prob get with their forums.
For the cert to pass using doh or dot it would have have the CN and SAN setup..
Are you saying your directed query via dot works, and your trying to get your redirection to this working.. You understand redirection to dot or doh is designed to fail.. Because if I am looking for dot.domain.tld and the cert sends me back host.other.tld the client should say hey wait a minute this is wrong!
If your just trying to forward in from one of your many wans ;) you show the port forwards but not the rules on the interfaces.. Port forwards not going to work unless the firewall allows it..
-
@johnpoz said in Cloudflare + BIND9 + pfSense DNS over TLS:
@FragRot so you have setup and doing a directed query not working with nginx as your offloader, I would suggest you prob get with their forums.
For the cert to pass using doh or dot it would have have the CN and SAN setup..
Are you saying your directed query via dot works, and your trying to get your redirection to this working.. You understand redirection to dot or doh is designed to fail.. Because if I am looking for dot.domain.tld and the cert sends me back host.other.tld the client should say hey wait a minute this is wrong!
If your just trying to forward in from one of your many wans ;) you show the port forwards but not the rules on the interfaces.. Port forwards not going to work unless the firewall allows it..
If I do dig google.com +tls it would return 127.0.0.53 which is my DNS server but if I do dig @x.x.com google.com +tls it would return an error. Now DoT works locally but when I point to my domain x.x.com it does not work.
So what you're saying is I need to configure DoT at pfSense level?
-
@FragRot I am really not understanding what your wanting to do to be honest..
Is bind local, is it hosted somewhere? Is your client going to directly talk to it, do you want pfsense to forward to it? Are you wanting to redirect to it if a client asks some other dot or doh server?
You have port forwards and local rules? So you want external clients to ask your NS for recursive?
If you want anyone to ask your NS for something using dot or doh, that is is not authoritative - Ie a recursive request. Then you need to setup dot and or doh on that server. And your cert needs to be valid for the name they will use to validate it.. Then you have thrown in some nginx server?
I setup unbound to do dot and doh, which I have zero use for and no love - just to see what was required to do so. And to see if could get the stupid warning off the phone about non private dns, etc. I set it up, but I don't actually use it ;) I resolve to find stuff, and locally it makes little sense to add the overhead of dot and or doh to the local query that only over my local network.
-
@johnpoz
I was testing your doggy command and I didn't get the same, was some error.
But that's probably because i'm running unbound in Forwarding mode and use SSL/TLS for outgoing DNS queries :)
That's mean i'm using upstream DNS servers, 9.9.9.11 and 149.112.112.11 :) -
@MoonKnight no it wouldn't matter if unbound is forwarder mode or not.. It listening for dot or doh would have nothing to do with that.. But you do need a valid cert.. and you have to put it on your pfsense seutp
For dot and doh I use this cert I created in the cert manager of pfsense, and just copied it up to the unbound install
You can use multiple different ways to get the CN and SAN info from the cert for verification, etc. See above simple openssl cmd to just pull the dns info out of my cert.
But you can also look at the cert directly.. For example here is my cert I put in the unbound folder, and I believe the unbound one is default? And I had played with it before using another cert with my old names and different IP of pfsense for it. the sslcert.crt
I should prob clean up that folder of certs not currently using ;)
It's been a while since I played with this - prob be a good idea to go over the unbound docs, if you look in the unbound conf you will what its using by default for the 853 (dot) when you click that checkbox.. But override that with my custom option, and also have it listen on 443 for doh.. It uses the same cert for both services.
-
@johnpoz
This is so cool, thanks. You gave me some idea to test this out sometime later. The unbound is default :)
-
@MoonKnight have fun ;)
I personally am not really a fan of dot or doh, but just because I have no use for it or no desire to use it doesn't mean shouldn't understand how to set it up or use it.. It is becoming more and more widespread.. And not saying it doesn't have valid use cases.. Just not really a fan of how browsers or apps or even OSes are pushing it without explicit opt in..
If you have created the next great mousetrap, then the world will beat a door to use it.. And that is fine - but you shouldn't on your own start changing things to use it without user acceptance and knowledge that you are changing where their application or OS gets dns from or how.
If I set my OS to use x.x.x.x for dns - that is what the OS should use, that is what every freaking application running on the OS should use - it shouldn't use anything else, without explicit user selection to do so. If you want to make it easy to do, sure - but it better well be with user opt in..
-
@johnpoz said in Cloudflare + BIND9 + pfSense DNS over TLS:
@FragRot I am really not understanding what your wanting to do to be honest..
Is bind local, is it hosted somewhere? Is your client going to directly talk to it, do you want pfsense to forward to it? Are you wanting to redirect to it if a client asks some other dot or doh server?
You have port forwards and local rules? So you want external clients to ask your NS for recursive?
If you want anyone to ask your NS for something using dot or doh, that is is not authoritative - Ie a recursive request. Then you need to setup dot and or doh on that server. And your cert needs to be valid for the name they will use to validate it.. Then you have thrown in some nginx server?
I setup unbound to do dot and doh, which I have zero use for and no love - just to see what was required to do so. And to see if could get the stupid warning off the phone about non private dns, etc. I set it up, but I don't actually use it ;) I resolve to find stuff, and locally it makes little sense to add the overhead of dot and or doh to the local query that only over my local network.
My BIND and NGINX server is hosted on a VM. I follow this guide. https://www.linuxbabe.com/ubuntu/dns-over-tls-resolver-nginx From my understanding, for client to talk to DNS server I have already port forward 53 and 853 at WAN interface on pfSense. What kind of firewall rule should I set? I have configured allow VLAN subnets to talk to DNS server on port 53 and 853. Would that surffice?
-
@FragRot said in Cloudflare + BIND9 + pfSense DNS over TLS:
lient to talk to DNS server I have already port forward 53 and 853 at WAN interface on pfSense.
What clients? Why would your "clients" be on the wan side of your pfsense? Seems like your not setting up your network correctly if your clients are in front of your router ;) And if you were going to use pfsense as an internal router, why would you even enable nat and have to deal with port forwarding?
You never showed your wan rules? If your "wan" or wans are rfc1918 space - you can port forward until doomsday and its not going to work unless you disabled the default block rfc1918 rule, and quite possible the bogon rules? I believe pfsense pulls rfc1918 out of the bogon listing?
Are these "clients" you want talking to your NS out on the internet in public IP space?
For your clients actually behind pfsense, yes all you would need is a rule to talk to your NS if on a different network/vlan what ports to use.. If your going to use dot or doh, there would be no reason to allow for 53.. just the dot and doh ports 853/443
-
@johnpoz said in Cloudflare + BIND9 + pfSense DNS over TLS:
@FragRot said in Cloudflare + BIND9 + pfSense DNS over TLS:
lient to talk to DNS server I have already port forward 53 and 853 at WAN interface on pfSense.
What clients? Why would your "clients" be on the wan side of your pfsense? Seems like your not setting up your network correctly if your clients are in front of your router ;) And if you were going to use pfsense as an internal router, why would you even enable nat and have to deal with port forwarding?
You never showed your wan rules? If your "wan" or wans are rfc1918 space - you can port forward until doomsday and its not going to work unless you disabled the default block rfc1918 rule, and quite possible the bogon rules? I believe pfsense pulls rfc1918 out of the bogon listing?
Are these "clients" you want talking to your NS out on the internet in public IP space?
For your clients actually behind pfsense, yes all you would need is a rule to talk to your NS if on a different network/vlan what ports to use.. If your going to use dot or doh, there would be no reason to allow for 53.. just the dot and doh ports 853/443
Yes you are correct the clients is from internet as well as clients from behind pfSense. I would want both to be able to access DoT from my DNS server.
-
@FragRot so those rules would block rfc1918 as the source coming into your wan1.. I see it has triggered, see the 772 B in the states column.
Also keep in mind with unbound you have ACLs - so out of the box unbound auto does the ACLs and allow anything that is directly attached to pfsense network to query unbound. If this is some public IP coming from the internet.. That would not be allowed by the ACLs on unbound that is for sure!!
but notice your rule there at the bottom for dot.. I see that rule has never triggered, see the 0/0.. That tells me that nothing has ever asked to use that rule.. So it was either blocked by the top rfc1918 rule. Or maybe you have rules in floating? But your rule to allow anything coming in wan1 IPv4 udp/tcp to port 853 has never triggered.. What exaclty do you have in the HxHDNS alias? maybe that is not matching? Port forward rules are evaluated first.. Then firewall rules are evaluated to see if what your trying to port forward is actually allowed by the firewall rule(s)..
-
@johnpoz
I have been reading on this forum that you are not a big fan of DoT's and DoH's :)
But I started to use it when it was announce at Netgate in 2018.
And have been using it since, with Quad9 DNS server: 9.9.9.11 and 149.112.112.11
They support TLS, DNSSEC:
@johnpoz said in Cloudflare + BIND9 + pfSense DNS over TLS:
Just not really a fan of how browsers or apps or even OSes are pushing it without explicit opt in..
Yeah, I feel the same. It's my devices so I like to choose what DNS they gonna use etc....It's so many devices out there, that are hardcode with some DNS.
Hopefully I have some rules that redirect all hardcoded shit back to pfSense's DNS :) I believe it works
-
@MoonKnight that is a bit different than setting up your own NS to answer queries sent to it via dot or doh.. But yeah do whatever floats your boat.. You do you.. If you like sending all your queries to some outside dns server - have fun.. I will just resolve my stuff ;) I have no desire to send my dns queries to any outside dns service. No matter how "secure" they say they are ;)
Be it I send it in the clear, or via dot or doh..
Hey some of these service can provide filtering, and that can be a good thing. But I will just do my own filtering, again thank you very much.. Hey and yeah if you had some network you were transiting (your isp for example) that is doing interception, and or manipulation in some way. Hey using dot or doh might be a way to mitigate that. So again it does have some valid use cases..
But none of those use cases apply to my needs currently.. So I see no point in sending my dns queries to any of those services..
edit: If I discovered my isp was manipulating my dns in any way, sure I would mitigate that with the best option.. Be that doh, or a vpn to one of my vpses out on the public internet.. And then I would be on the hunt for a new isp ;) I still would not need to send my dns to any of these services. I would just run a resolver on my own vps..
-
I tried to use my phone to connect to DNS server via my domain x.x.com and traffic appears on pfSense firewall. Does this mean I need to look at other places as I can see traffic being passed on pfSense firewall? I have checked port 853 is allowed on DNS server via UFW.
-
@FragRot well pfsense sent it on.. So if your not getting a response, or the response you want even though you got a syn,ack - that points to something on your destination box yeah.. Your in time wait, and you have traffic in both directions..
Maybe you got a refused back because of lack of ACL on unbound?
-
@johnpoz said in Cloudflare + BIND9 + pfSense DNS over TLS:
If you like sending all your queries to some outside dns server - have fun.. I will just resolve my stuff ;) I have no desire to send my dns queries to any outside dns service. No matter how "secure" they say they are ;)
But that's mean you are sending everything out in plain text? And you probably don't have any DNS under General Setup. Just "Use local 127.0.0.1, ignore remote DNS servers" ?
But you still use some DNS somewhere?
Ah man I wish you had made a tutorial of your setup :) -
@MoonKnight said in Cloudflare + BIND9 + pfSense DNS over TLS:
But that's mean you are sending everything out in plain text?
Yeah.. So? I could give 2 shits if my isp knows I did a query for domainx.tld.. As long as they don't try and manipulate it or filter in any way I don't care.
Do you really think your hiding where your going from your isp with dot or doh? You understand after you lookup the ip for that domainX.tld the sni you send to talk to domainX.tld is in the clear.. Its part of the handshake... So while you might hide the dns query that you asked about domainX.tld.. They can just as easy pull that from the sni.. when you do your handshake with the server.
Until such time that esnsi (now dead), long live ech is main stream and everywhere.. And I can tell you that is a long way off.. Because it has to be done by the server admin hosting said service. Hiding your dns queries doesn't get you the privacy from your isp most people believe it does because they believe some ad somewhere or some article they read that says hey send all your dns to us, we care about your privacy - your isp is spying on you and selling it to the highest bidder, which we would never do ;)
My dns being the clear gives me ease of troubleshooting what is being asked, what is being returned. It has no extra overhead. Anything I do on the internet, what I order from amazon, etc. my isp has no clue what I do on the site, other than the amount of data being moved. They don't know I went to domainX.com/something/whatever - they just know I did a query for domainX.tld or something.domainX.tld and went to said IP address.. Which they can get from just the traffic to said IP address, and what domain that was was in the sni..
I could put together a simple guide I guess, its basic stuff really.. But to be honest that would be somewhat of an endorsement of doing it - which I am not a fan of.. I don't have any problem showing you my config and discussing how to create a cert in cert manager if you want to do such a thing. But I just don't have any desire to try and walk through some user how to do something they think is providing them with security, when its not.. And to be honest while sure dot and doh have some use cases when your forwarding to some outside service. I just don't see why anyone would actually feel the need to do it locally - Is your local network hostile? Are there people on your local network sniffing your traffic? Again if they are sniffing your local traffic, the sni is in the clear. Just as easy to sniff that as it is your dns queries.
I did it as a learning exercise, and it took all of few minutes. I don't actually use it.. I leave it up because there really isn't any reason to tear it down.
-
I found this post and this is exactly what I want to do. https://serverfault.com/questions/1034535/pfsense-dns-port-forwarding Instead of setting NAT reflection to Enable (Pure NAT) I tried setting Enable (NAT + Proxy) and I'm able to see result when I dig with my domain x.x.com. Unfortunately, I'm still unable to connect to DoT from my Android phone.
