Describe the bug

If you just set serve-expired: yes in your config, then unbound could serve stale dns entries for ever as the default value for serve-expired-ttl is 0. This is not a secure configuration.

To reproduce
n.a.

Expected behavior

unbound should also follow suggestions from RFC-8767 and not just recommendation and therefore set a non-zero default value for serve-expired-ttl. The decision to serve expired data forever should be an explicit decision by the user as they put themselves at risk by doing so. See below for why.

System:
n.a.

Additional information

1. Security issue

As background and to explain why this should probably be considered a security issue, I was bit by this last week when I was performing an online payment when my browser stopped the request as I was about to be redirected to an unsecure page/domain.
After investigating I noticed that the SSL certificate of the page I was on did not belong to the PSP that was handling the payment but some random other third party. After contacting the PSP they mentioned that they had reason to believe this was caused by DNS caching. Although I didn't believe them at first, after diving into the unbound config more I'm quite sure they were right (sry PSP).
Looking at the unbound logs, I had last visited that PSP checkout page something like a month ago and I guess that when I first requested the PSP's checkout page last week that unbound served the cached DNS response from last month. But it seems that in between last month and last week, the PSP scaled down/changed their capacity causing the resources they used last month to not be used anymore. And their cloud provider had allocated those resources to another third party.

TLDR: this is a security issue as due to this default unbound configuration I almost submitted personal / payment information to some random third party as unbound served me a month old DNS record. Luckily my browser stopped me from doing that.

2. RFC

Also, I wonder whether unbound does really adhere to RFC-8767. Unbound says about enabling serve-expired that it attempts to serve old responses ... without waiting for the actual resolution to finish. But section 7 of the RFC says that a good-faith effort has been recently made to refresh the stale data before it is delivered to any client.
I might misunderstand the RFC here, but it seems the RFC says an attempt to refresh has to be made while unbound immediately sends stale data without trying to refresh? I guess that unbound could better adhere to the RFC by also setting a non-zero value for serve-expired-client-timeout by default.

3. Mitigation

Instead or in addition to setting serve-expired-ttl, maybe a setting like serve-expired-ttl-factor could be added. This might be outside the scope of RFC-8767, but the party who knows best how long DNS data should be cached is the owner of the DNS recordset who already sets a TTL themselves. And setting a fixed duration for serve-expired-ttl seems wrong as it doesn't take the intentions of the original DNS owner into account. A setting like serve-expired-ttl-factor: 10 could be added to work next to serve-expired-ttl, where serve-expired-ttl is the maximum value and serve-expired-ttl-factor means that unbound only serves stale cache data for the configured factor value times the TTL that the owner of the DNS record configured.

F.e. setting a config like:

serve-expired-ttl: 86400
serve-expired-ttl-factor: 10

could mean that when requesting a DNS record with a configured TTL of 60 seconds would then only be cached for 10 * 60 = 600 seconds while a DNS record with a TTL of 10.000 would be cached for 86400 seconds (and thus not 10 * 10.000 = 100.000)