TrueNas Scale - Enable DNS Over HTTPS (DOH) or DNS over TLS?

[scotrod]

Hey All!

I'm trying to find a way to implement DNS Over HTTPS (DOH) or DNS over TLS on my TrueNas Scale instance, and at least in the GUI I cannot find option for either. Is there a vanilla way of doing this and if no, would it be okay to do it via Linux shell?

Thanks!

 

[sretalla]

I doubt that changes via the shell would stick.

I guess the way to do that might need to be something like running an app that does it and pointing the host at the app (risky as the app may fail to start and the host may not be healthy without the app).

If that were important to me, I would be doing the secure DNS from my firewall/router.

 

[scotrod]

I doubt that changes via the shell would stick.

I guess the way to do that might need to be something like running an app that does it and pointing the host at the app (risky as the app may fail to start and the host may not be healthy without the app).

If that were important to me, I would be doing the secure DNS from my firewall/router.

The thing is, I am using pfBlockerNG on top of pfSense for my router, firewall & DOH solution and I cannot find a way to whitelist a single host from there. I thought that simply adding a static DNS entry from the TrueNas instance would be easier, as for the last few years almost every OS has this functionality build in.
I will check if there ain't application that can do this for me, thanks for the suggestion.

 

[sretalla]

pfBlockerNG on top of pfSense for my router, firewall & DOH solution and I cannot find a way to whitelist a single host from there

Not sure I get what you mean... do you mean whitelisting something in pfBlocker (easily done) or in pfSense (also easily done with a firewall rule)?

 

[scotrod]

Not sure I get what you mean... do you mean whitelisting something in pfBlocker (easily done) or in pfSense (also easily done with a firewall rule)?

pfBlocker. I am using it for a few weeks and I found no way to whitelist a single local IP from pfBlockerNG's "bloc" range. I need TrueNas to be outside of my "block" range so it can reach all the trackers I point it to (since my *arr apps are installed on it).

 

[elvisimprsntr]

Since you are running pfSense, why not implement it there? I've been doing that for years.

1. Enable DNS Resolver DNSSEC and SSL/TLS

2. Add a FW rule to redirect all (or selected IP ) outbound port 53 DNS queries to DNS Resolver, which will then redirect them using port 853

 

[scotrod]

@elvisimprsntr Thanks for the reply. I already have DNS over TLC setup on the pfsense, along with pfblockerNG working there. The thing is, I want my TrueNas to bypass the pfblockerNG filtering. Since I am not familiar with pfSense/pfblockerNG at all, I was thinking that setting a single DNS entry on TrueNas will be easier.

 

[sretalla]

Maybe check this one out:

Bypassing DNSBL for specific IPs

Not sure if this has been posted before but just figured out views are possible in Unbound 1.6 and can be used for bypassing DNSBL zones for specific IPs/ran...

forum.netgate.com

 

[scotrod]

Maybe check this one out:

Bypassing DNSBL for specific IPs

Not sure if this has been posted before but just figured out views are possible in Unbound 1.6 and can be used for bypassing DNSBL zones for specific IPs/ran...

forum.netgate.com

Thanks. I used unbound (python managed) and group policy to whitelist TrueNas' IP, so I have the DNS part straight. The IP filtering still persist.
Since I don't want to turn this into pfsense/pfblockerNG discussion, I still want to understand if TrueNAS has this capability at all, since it is a good thing to have.

 

[sretalla]

I still want to understand if TrueNAS has this capability at all, since it is a good thing to have.

I think it doesn't... short of just not pointing it at your pfBlocker IP for DNS (just go straight to google or something).

 

[scotrod]

I think it doesn't... short of just not pointing it at your pfBlocker IP for DNS (just go straight to google or something).

I will try to raise a feature request tonight... I still think that having this implemented on OS level is a nice thing to have. Not everyone is using fancy router/FW gear or has access/knowledge to setup DOH/DOT on a router level.

 

[ChrisRJ]

@elvisimprsntr Thanks for the reply. I already have DNS over TLC setup on the pfsense, along with pfblockerNG working there. The thing is, I want my TrueNas to bypass the pfblockerNG filtering. Since I am not familiar with pfSense/pfblockerNG at all, I was thinking that setting a single DNS entry on TrueNas will be easier.

I would strongly recommend to solve this in pfSense for the following reasons:

• It is the correct place from an architectural perspective. This is not only a theoretical point but also goes to practical security. One of the main reasons for bad security is that by mixing tasks, it is relatively easy to introduce side-effects that boil down to security holes.
• It does not make sense to invest time in learning to do things in the wrong place. Rather look how to address this in pfSense. Besides, running a system that is critical for security, always makes it a candidate to learn as much as possible about it.
• Features that are not the core competency of a system, will never receive the same level of care as the primary ones.
• Using TrueNAS for DNS stuff is a bit like ignoring an existing ESXi server with available capacity and run VMs on TrueNAS . Running the VMs is possible on TrueNAS, but for advanced use-cases like fail-over an ESXi cluster offers much better service.
• Coming back to the first point, once the initial hurdle has been overcome, it almost always is easier to have things in the proper place.

 

[scotrod]

I would strongly recommend to solve this in pfSense for the following reasons:

• It is the correct place from an architectural perspective. This is not only a theoretical point but also goes to practical security. One of the main reasons for bad security is that by mixing tasks, it is relatively easy to introduce side-effects that boil down to security holes.
• It does not make sense to invest time in learning to do things in the wrong place. Rather look how to address this in pfSense. Besides, running a system that is critical for security, always makes it a candidate to learn as much as possible about it.
• Features that are not the core competency of a system, will never receive the same level of care as the primary ones.
• Using TrueNAS for DNS stuff is a bit like ignoring an existing ESXi server with available capacity and run VMs on TrueNAS . Running the VMs is possible on TrueNAS, but for advanced use-cases like fail-over an ESXi cluster offers much better service.
• Coming back to the first point, once the initial hurdle has been overcome, it almost always is easier to have things in the proper place.

I agree with all those points, but I still think that every modern OS should have the capability to do either DOH or DOT... or why not both. Not sure about your TrueNAS comment BTW... I never wanted to install any VMs on TrueNAS :D

 

[Patrick M. Hausen]

The OS should use the managed resolver provided via DHCP. And not go out on its own to actively circumvent that. Besides DoH is a huge privacy risk that should never have been deployed in the first place. DoT is a different matter but should still be left to the local recursive name server. Even worse are applications, most notably browsers, bypassing the OS's resolver library to connect to $somewhere out of the administrator's control.

 

[pinoli]

Besides DoH is a huge privacy risk that should never have been deployed in the first place.

this statement got my attention, because CloudFlare states the exact opposite on the issue in this page comparing DoH and DoT.

However, from a privacy perspective, DoH is arguably preferable. With DoH, DNS queries are hidden within the larger flow of HTTPS traffic. This gives network administrators less visibility but provides users with more privacy.

can I ask you to elaborate? I am very interested

 

[Patrick M. Hausen]

this statement got my attention, because CloudFlare states the exact opposite on the issue in this page comparing DoH and DoT.

You give all details of every single recursive DNS request to Cloudflare. Do you trust them? I don't. Not that I know of any actual misconduct on their part, but why give away all this sensitive private information?

When you run your own recursive DNS server and let's assume it's freshly started and therefore the cache empty ...

Client asks for e.g. www.truenas.org

Cloudflare scenario: Cloudflare gets a request for www.truenas.org.

Own recursive DNS:

One of the root nameservers gets a request for the nameservers for com and returns a list.
One server from this list gets a request for truenas.com and returns a list.
One of these servers gets the request for www.truenas.com and returns an address.

This is far superior from a privacy point of view in my opinion.


The point most people miss: there is no reason to use your ISP's nameservers. There is no reason to use any "upstream" nameserver at all. DNS is a distributed database. Put BIND or Unbound on an Internet connection and it will resolve DNS requests all on its own.

 

[pinoli]

You give all details of every single recursive DNS request to Cloudflare. Do you trust them? I don't. Not that I know of any actual misconduct on their part, but why give away all this sensitive private information?

When you run your own recursive DNS server and let's assume it's freshly started and therefore the cache empty ...

Client asks for e.g. www.truenas.org

Cloudflare scenario: Cloudflare gets a request for www.truenas.org.

Own recursive DNS:

One of the root nameservers gets a request for the nameservers for com and returns a list.
One server from this list gets a request for truenas.com and returns a list.
One of these servers gets the request for www.truenas.com and returns an address.

This is far superior from a privacy point of view in my opinion.


The point most people miss: there is no reason to use your ISP's nameservers. There is no reason to use any "upstream" nameserver at all. DNS is a distributed database. Put BIND or Unbound on an Internet connection and it will resolve DNS requests all on its own.

This is all very clear, a locally-hosted DNS resolver is the best choice when it comes to privacy; my bad, I thought you were singling out DoH over alternatives.

But short of running your locally-hosted DNS resolver, DoT/DoH are vastly superior to the current SCALE implementation (plaintext requests).
And DoH tangibly improves privacy, since at least your ISP won't even see/know you are making DNS requests.
So, while I'd welcome anybody willing to run their recursive DNS resolver (as I am about to do with an OPNSense box), I believe TrueNAS SCALE should support DoT/DoH out of the box as a minimum, reason why I opened a ticket here.

They are fairly widespread protocols and supported virtually by every public DNS service. And while I agree DoH with CloudFlare/Google/etc.. can give you a false sense of privacy, once enabled the DNS provider becomes your only concern: on the other hand, in the absence of DoH/DoT, anybody can snoop on your DNS queries.

Considering everything is already present in SCALE to support both protocols (resolverd and coredns both support DoH/DoT), I would argue why not?