Resolver vs Forwarder

[McMurphy]

We use DNS forwarding and the question is should I implement the dns forwarder or dns resolver and enable forwarding mode?

Is there a difference and is one better than the other?

[SteveITS]

@McMurphy Resolver replaced Forwarder as the standard years ago so we’ve always used it.

[keyser]

@McMurphy As @SteveITS mentioned, the resolver became the default (replacement) for the forwarder many years ago.
The Resolver offers a LOT of features compared to the forwarder - A few examples of the “heavy” features:

1: Multithreaded (regardless if operating in forwarding or resolver mode) = Much better performance when you have LOTS of clients
2: Integration with KEA DHCP to have clients dynamically DNS registered (again, regardless of in forwarding or resolver mode)
3: Integration with Python scripts for dynamically filtering DNS as best seen when combined with pfBlockerNG = EXCELLENT DNS filtering options. (Again, regardless of working in forwarder or resolver mode)

[patient0]

And it should be mentioned that you can use the resolver as a forwarder, too. There's a checkbox in the Resolver (Unbound) called 'DNS Query Forwarding' in which case the DNS servers specified in System / General Setup are used.

[McMurphy]

So if I need a fwd, best to use resolver in fwd mode?

[keyser]

@McMurphy That's what I would do, yes. But if your environment is Small (< a few hundred clients), and you are not looking to do DNS filtering or Client DNS registrations, the Forwarder will work fine - and use less memory

[Gertjan]

@McMurphy said in Resolver vs Forwarder:

So if I need a fwd, best to use resolver in fwd mode?

Need forwarding ?
Long story short : you probably want (need ?) a safe, secured DNS **. As soon as you understand why DNSSEC was invented, you'll go through the classic phase ".... silence ... then the big 'OMG'", and you switch to local resolving mode right away (== back to pfSense default).
Start by asking (yourself) this question : why, when you install pfSense, unbound is set up by default using resolving ? Why did Netgate made this decision for us ?

** not a hidden, invisible, encrypted one, but a good, non spoofed DNS answer. Remember : if DNS falls (fails to give the correct answer), TLS (https, TLS, encryption falls as certificate issue go undetected) and that will bring world's economy to a stand still in no time.

Forwarding is still possible, as the big 'public' (private actually) DNS resolvers like 8.8.8.8 1.1.1.1 etc etc have huge budgets to distribute to 'influencers' who make us convince that we need to forward (to them). These companies don't do this to do us a favor, noop. It is and was always about one thing : $ or €.

I'm not saying that forwarding is bad, it's still there, and pfSense even kept the original forwarder in place (dnsmasq) so you can use it.

[McMurphy]

@Gertjan

I wanted to push all client DNS via Quad9 hence the fwd.

[SteveITS]

@McMurphy
FWIW if you want to forward encrypted:
https://docs.quad9.net/Setup_Guides/Open-Source_Routers/pfSense_(Encrypted)/

I did recently learn Quad9 (and Google) have a maximum TTL. CloudFlare Family (malware protection) does not. Just FYI.

[McMurphy]

Is there a benefit over Quad9 vs CloudFlare as I understand they both do a similar job?

[johnpoz]

@McMurphy yup they pretty much do the same thing. Pick your poison - maybe one of them has a closer instance to you than the other. One might be overall larger footprint globally - but does that matter to the end user?

Their filtering lists prob differ, etc.

Who do you "trust" more?

Personally unless I had a valid technical reason like on a really slow like sat connection or something I would never forward.

Guess if you are in a region of the world or on an isp likes to filter/intercept your dns than sure use of doh might allow you to resolve stuff you could not with just normal clear dns.

Currently I do not have any of those sorts of issues - so I resolve.

[tinfoilmatt]

Personally unless I had a valid technical reason like on a really slow like sat connection or something I would never forward.

There's also a privacy argument to be made here for DoT (forwarded to a trusted DoT provider, of course). Although—if you're tunneling all outbound traffic to a trusted VPN provider anyway, then that argument is weakened.

Then it's squarely 'pick your poison':

1.) Forward all queries via DoT to a trusted DoT provider, which will somewhat blend your lookups in with your trusted VPN provider's fellow customers from the DoT provider's perspective; or
2.) Resolve via the first-hop tunnel but otherwise in the clear, and trust that your VPN provider isn't subject to any wide-scale pattern analysis and/or 'trust' the 'blending in' effect.

ETA: I currently employ the belt-and-suspenders #1 approach. But, in my limited understanding of DNSSEC, #2 would allow me to make use of it.

[johnpoz]

@tinfoilmatt said in Resolver vs Forwarder:

But, in my limited understanding of DNSSEC, #2 would allow me to make use of it.

if you forward - where you forward is either doing dnssec or they are not. Most of the major players for sure do it anyway - some do provide alternate IP to use that does not do it.

But again if you forward you are trusting them in their dnssec as well.

If you forward you shouldn't be asking for dnssec as well - this can have issues. Again if you forward they are already doing it or they are not. Asking them to do it won't do anything but add more queries and could be problematic. So if you are using the resolver to forward - you should really uncheck the do dnssec box.

[tinfoilmatt]

So if you are using the resolver to forward - you should really uncheck the do dnssec box.

Agreed.

[tinfoilmatt]

I'm kinda stuck on this point actually: is there really no benefit whatsoever to be gained from forwarding with Unbound configured to enable DNSSEC support?

I happen to have the box checked even though I'm forwarding, and I see the relevant DNSSEC records in Unbound's cache. Is it true that Unbound isn't actually doing anything with these RR sets?

[SteveITS]

@tinfoilmatt Forwarding + DNSSEC can result in failed queries, see the Quad9 URL above ("DNSSEC is already enforced by Quad9, and enabling DNSSEC at the forwarder level can cause false DNSSEC failures"), or https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-config.html#dns-resolver-options:~:text=DNSSEC%20may%20need%20to%20be%20disabled

Essentially, we trust the DNS servers to do DNSSEC for us.

[tinfoilmatt]

I don't usually do this, nor have I independently verified by consulting the Unbound documentation, but this LLM answer is convincing enough for me to dive deeper:

PROMPT:

Spoiler

If operating a DNS recursive resolver in 'forwarding mode only', is there any benefit to be gained from enabling DNSSEC capabilities?

ANSWER:

Spoiler

Yes — there can be a significant benefit, even when the resolver operates in forwarding-only mode. The key is that forwarding and DNSSEC validation are separate functions.

If you're thinking specifically of Unbound, this is an important distinction.

What forwarding-only means

With something like:

forward-zone:
   name: "."
   forward-addr: 9.9.9.9

your Unbound instance isn't performing the iterative recursion itself. It sends the query to the upstream recursive resolver, which does the recursion on its behalf. Unbound's documentation explicitly describes a forwarder as another recursive resolver that handles the further recursion.

But Unbound can still perform DNSSEC validation locally.

Why validate locally?

Suppose your upstream resolver says:

www.example.com → 203.0.113.10

and the zone is DNSSEC-signed.

If your forwarding resolver doesn't validate DNSSEC, you're essentially trusting the upstream resolver to give you the correct answer.

If you enable DNSSEC validation, your resolver can independently verify the DNSSEC chain of trust. If the cryptographic validation fails, it can return SERVFAIL rather than accepting the forged/invalid answer. Microsoft describes the same principle for forwarding DNS servers: DNSSEC validation can be performed by a forwarding resolver, and a validation failure results in SERVFAIL.

So the architecture becomes:

                DNSSEC
                 ↓
Client → Unbound → Forwarder → Authoritative DNS
            │
            └── validates DNSSEC

rather than:

Client → Unbound → Forwarder → Authoritative DNS
                        ↑
                 "I trust this guy"

But there's an important caveat

Your forwarder needs to support DNSSEC appropriately.

For example, if you forward everything to a recursive resolver that strips DNSSEC information or otherwise prevents your local resolver from obtaining what it needs for validation, local validation can fail. Unbound's documentation specifically notes that a forwarding proxy that isn't DNSSEC-capable can cause validation to fail.

Consequently, if you're going to run:

forward-zone:
   name: "."
   forward-addr: <upstream>

with DNSSEC validation enabled, choose an upstream recursive resolver that properly supports DNSSEC and permits the necessary DNSSEC records to be obtained.

There's another benefit: you don't have to trust the forwarder's validation

This is probably the most interesting point.

Imagine the upstream resolver is operated by somebody else. It says:

"I validated this answer; trust me."

With local DNSSEC validation, you aren't relying solely on that assertion. Your resolver performs the cryptographic validation itself.

That's particularly useful if the forwarder is:

• an ISP's resolver;
• a corporate DNS server;
• a home router;
• a locally operated resolver you don't completely trust;
• or a third-party recursive DNS service.

The DNSSEC security model is specifically compatible with a forwarding architecture; RFC 7901 describes a validating resolver as one that performs DNSSEC validation and notes that a system can be configured as a forwarding resolver while still requiring local validation.

One subtle point with Unbound

Unbound's forwarding behavior means it sends the query upstream, but it doesn't simply accept the upstream resolver's DNSSEC verdict as authoritative. Historically, Unbound's developers have explicitly explained that forwarded queries are sent with CD=1, meaning the forwarder is asked not to perform validation on behalf of Unbound; Unbound can then perform its own validation.

So, conceptually:

                DNSSEC validation
                       ▲
                       │
Client ──→ Unbound ────┼──→ Forwarder ──→ Internet
                       │
                       └── validates answer

Bottom line

If you're running a forwarding-only recursive resolver, I'd generally say:

Enable DNSSEC validation if you want the resolver itself to provide DNSSEC security.

Forwarding-only does not make DNSSEC pointless. In fact, it gives you a useful security property: you can use somebody else's recursive infrastructure while retaining local cryptographic validation of DNSSEC-signed domains.

The main thing to distinguish is:

• DNSSEC validation → protects the authenticity/integrity of DNS data.
• DNS-over-TLS/HTTPS to the forwarder → protects the DNS query/response in transit between you and the forwarder.
• Forwarding-only → determines who performs the recursive lookup.

Those three are independent.

If you're configuring Unbound specifically, I can also explain the somewhat confusing interaction between forward-zone, val-permissive-mode, harden-dnssec-stripped, CD, AD, and forward-tls-upstream—that's where the practical details get interesting. [sic]

[tinfoilmatt]

With local DNSSEC validation, you aren't relying solely on that assertion. Your resolver performs the cryptographic validation itself.

I don't think I agree with that statement based on the fact that Unbound is still going to need to perform its validation lookups by querying the configured recursive resolver/s it's forwarding to.

[SteveITS]

@tinfoilmatt all I know is it broke in 23.01 and we turned it off everywhere. I found these in a quick search.

https://forum.netgate.com/post/1091473
https://forum.netgate.com/topic/178050/solved-intermittent-dns-problem-23-01

[tinfoilmatt]

Well yes, my question assumes a valid and bug-free configuration of all softwares involved. I'm pretty sure the devil's going to be in the unbound.conf(5) keyword details.