Fill the gap with Unbound functionality

[wellloaded]

Hello Sara, I came across this comparison table between Stubby and Unbound. I wasn't aware of this but it seems like there are indeed some gaps in terms of functionality that could (should?) be filled by Stubby:

Criteria	Stubby	Unbound
License	BSD 3-Clause	BSD 3-Clause
Implementation language	C	C
DNS-over-TLS (DoT)	Yes	Yes
DNS-over-HTTPS (DoH)	Yes	Yes
DNS-over-QUIC	Yes	Yes
DNSSEC Validation	Yes	Yes
Cache	No	Yes
Recursive queries	No	Yes
Forwarding	Yes	Yes
Load Balancing	No	Yes
Multiple Root Support	No	Yes
Round-robin DNS	No	Yes
Response Rate Limiting	No	Yes
API	Yes	Yes
Operating Systems supported	Linux, macOS, Windows	Linux, macOS, Windows

HTH
Thanks

[ArchangeGabriel]

The consensus here is that you should run both together: Unbound as your local DNS resolver, and Stubby as its upstream to relay requests with Do* to selected upstreams (because it at least used to be better in this field). Though that looking at your table, I might be in need to update my Unbound knowledge if that one supports all DNS-over-* as well as Round-robin (something that was requested for Stubby).

[saradickinson]

Hi there,

Can you point to where you found this as I think it needs some correction/clarification. Some of the criteria only make sense for Unbound when acting as a recursive resolver (e.g Load balancing, Multiple root support, Response rate limiting.....)

Firstly, Unbound is a validating, recursive, caching DNS resolver that can also be configured as a forwarding proxy.

• When it is deployed as a recursive resolver it has server side properties for listening to clients and sends queries to authoritative servers upstream
• When it is configured as a local forwarding proxy it acts as a client to send queries to an upstream recursive resolver

In both scenarios it can do DNSSEC validation and caching.

Stubby (as packaged) is just a validating, forwarding proxy (hence no cache, no recursion).

Historically Stubby had support for forwarding over DoT quite a while before Unbound and also had many more configuration options to better manage the DoT connections to upstream resolvers. Unbound now supports basic DoT forwarding, but still doesn't have all the configuration that Stubby does.

So (as @ArchangeGabriel said) what many folks do is run Unbound locally as a forwarder to provide local DNSSEC validation with a cache, and then queries from Unbound are sent via Stubby which forwards them to a recursive over DoT.

Example config for this is here
Implementation status of privacy related features is here

Some further points:

• Both support forwarding queries over DoT, and Unbound can listen on DoT as a recursive resolver
• Neither support forwarding queries over DoH, but Unbound can listen on DoH as a recursive resolver
• Neither support forwarding queries DoQ, but Unbound has new experimental code to listen on DoQ as a recursive resolver.
• I suspect the 'round-robin' criteria for unbound refers to how it chooses authoritatives to query, not its behaviour as a forwarder..... However @wtoorop can probably say more about Unbounds current forwarding policy for multiple servers?

[ArchangeGabriel]

@saradickinson Doing some triaging in my GitHub notifications emails I reviewed #330 and with this too, I think that Stubby binding to 53 by default is not ideal. It makes people think that Stubby should be used on its own while it does not do caching.

Maybe having a different default port and insisting in comments/documentation that a caching recursive resolver should be used in front would be better. And would allow for better security with PrivateUsers by default.

But anyway, Stubby and getdns do not seem to get much traction these days, so…

[wellloaded]

Hi there,

Can you point to where you found this as I think it needs some correction/clarification. Some of the criteria only make sense for Unbound when acting as a recursive resolver (e.g Load balancing, Multiple root support, Response rate limiting.....)

Apologies for the long delay in the answer. I'm uncertain on the actual source/investigation but this was picked up from the tomato forum:
https://www.linksysinfo.org/index.php?threads/tomato-unbound.77832/post-341744