Difference between DNS Resolver forwarding mode and DNS Forwarder?

[rcfa]

Under "Services > DNS Resolver" there's an option "Enable Forwarding Mode"; so what's the difference between enabling that, and enabling "Services > DNS Forwarder"?

Also, if the "Enable Forwarding Mode" is set, and in "System > General Setup" "Use local DNS, fall back to remote DNS Servers" mode is selected, will actually all queries still be forwarded (and only be locally cached), or will the system still first act as a recursive DNS resolver, and only fall back to the remote DNS Servers when things fail?

In essence, I want the system to pretend to be a DNS Server to clients on the LAN and cache results, but I don't want any original query to bypass the Quad9 servers, which I have set up as DNS Servers with TLS, so I don't want the system to be "enterprising" and start its own recursive queries...

[keyser]

@rcfa said in Difference between DNS Resolver forwarding mode and DNS Forwarder?:

Under "Services > DNS Resolver" there's an option "Enable Forwarding Mode"; so what's the difference between enabling that, and enabling "Services > DNS Forwarder"?

Also, if the "Enable Forwarding Mode" is set, and in "System > General Setup" "Use local DNS, fall back to remote DNS Servers" mode is selected, will actually all queries still be forwarded (and only be locally cached), or will the system still first act as a recursive DNS resolver, and only fall back to the remote DNS Servers when things fail?

In essence, I want the system to pretend to be a DNS Server to clients on the LAN and cache results, but I don't want any original query to bypass the Quad9 servers, which I have set up as DNS Servers with TLS, so I don't want the system to be "enterprising" and start its own recursive queries...

I don’t think there is any functionally difference. I believe the “DNS Forwarder” service is deprecated and will disappear in future releases, because “enable forwarding mode” in resolver does the same thing.

If you are using “Enable forwarding Mode”, the only difference to the system setting “use local, fall back to remote..” is - as you guessed - local caching of responses if the local DNS service is up.

[johnpoz]

@keyser said in Difference between DNS Resolver forwarding mode and DNS Forwarder?:

I don’t think there is any functionally difference

Not exactly - there are for sure some differences on how things are done and specific features. But yes generally speaking they are the same. Forwarder forwards, and unbound can be set to forward as well. But for example the forwarder dnsmasq can be set to forward sequentially to different NS, or can query all of of the forwarders you have listed at the same time and use the first response. Unbound can not do that afaik.

If you want to use pfblocker - unbound would be required to be used, be it default resolving mode or in forwarder mode.

So from a high level if your going to forward, either can be used. But there are things that might make it better to use one vs the other.

If you wanted to do tls mode in your forwarding, unbound would allow for that, etc.

[rcfa]

@keyser Thanks.
Perfect. Because I want encrypted DNS lookups for privacy, yet local caching. So Quad9 DNS Servers with TLS in forwarding mode with the standard DNS server policy seems to just do what I want.

[keyser]

@rcfa said in Difference between DNS Resolver forwarding mode and DNS Forwarder?:

@keyser Thanks.
Perfect. Because I want encrypted DNS lookups for privacy, yet local caching. So Quad9 DNS Servers with TLS in forwarding mode with the standard DNS server policy seems to just do what I want.

Yeah, if you REALLY trust the Quad9 service for privacy, that would be the way to go.

Just out of curiosity, what kind of additional latency does TLS to quad9 add to initial lookups for you, compared to either your own recursive resolution or your isp’s servers?

[rcfa]

@keyser Frankly, no idea. DNS lookups aren’t really a performance concern for my use case.

Or in other words, if surfing the web isn’t noticeably slower, it’s not an issue. The rest of connections is a fairly stable set of web/VoIP/chat servers, that likely most of the time are served from various caches.

I don’t have an environment where it connect at high frequency to ever changing set of sites.

[rcfa]

@keyser As for Quad9, it’s a Swiss NPO, and thus at least in principle more trustworthy than any of the other globally available, US based DNS services.

They hide my queries from geedy ISPs, do a moderate level of threat filtering, so it’s all good; if government level agencies try to track me, they have other means; as long as I get around the volume of consumer ISPs, MIM attacks, etc. I already got rid of a number of issues with little effort.

Countermeasures are cumulative, so I don’t expect to solve all my issues by using Quad9.

[keyser]

@rcfa said in Difference between DNS Resolver forwarding mode and DNS Forwarder?:

@keyser As for Quad9, it’s a Swiss NPO, and thus at least in principle more trustworthy than any of the other globally available, US based DNS services.

They hide my queries from geedy ISPs, do a moderate level of threat filtering, so it’s all good; if government level agencies try to track me, they have other means; as long as I get around the volume of consumer ISPs, MIM attacks, etc. I already got rid of a number of issues with little effort.

Countermeasures are cumulative, so I don’t expect to solve all my issues by using Quad9.

Thanks. It’s actually a rather interesting idea. I sort dismissed the thought a couple of years ago as I find recursive lookups “less dependant”, but obviously there are some security gains here - and if you trust Quad9, quite a lot of privacy as well.

Perhaps I’ll do some experiments on how it performs…

[rcfa]

@johnpoz said in Difference between DNS Resolver forwarding mode and DNS Forwarder?:

If you want to use pfblocker - unbound would be required to be used, be it default resolving mode or in forwarder mode.

OK, thanks, that makes dnsmasq a non-starter.

I guess that should be documented in the package system. I don't see it indicated like some of the routing packages list that they are not compatible with each other.

I think these sort of "hidden" incompatibilities need to be much better documented and pointed out.
If you had not mentioned this here, might at some point in the future maybe tried to use the package, and then wondered why things don't work as expected...

[Gertjan]

@rcfa

pfBlockerNG can be installed and work with dnsmasq.
The first 'IP' based part isn't DNS related at all, it's just pfBlockerNG, after all 'Blocker' says "it blocks" using 'pf' and 'pf' is the pfSense firewall. DNS has nothing to do with this.
People wanted more (as usual) so the local DNS handling had to be intercepted so more sophisticated host name (DNS) filtering could be applied. dnsmasq can't do that. Unbound can.

The DNS part, shows :

which means what it means.
dnsmasq is still an option present in pfSense for historical reasons. There will be a day that there isn't a choice anymore. It will be 'unbound' the resolver, and that's it.

As far as I know, unbound can do what dnsmasq does, that's why it was chosen.

All this is "IMHO" of course.

If it was me, I had thrown in the super bloat ware called 'bind' but bind can't really be mastered with a GUI as it is (to) big - and complex as it it masters 99,x % of all DNS interactions.
bind would solve the question of this thread, as it it wouldn't exist anymore. Everybody would know the answer already as everybody would know 'enough' about DNS to answer for themselves ;)

pfSense needed a resolver (which is neutral and doesn't feed external companies with user's private info) and a local DNS cache. zone handling etc isn't the role of a firewall anyway.
unbound has a rather small footprint, and can be 'extended' using scripting (Python). The choice was easy.