serve-expired behavior

[billatq]

Describe the bug
Unbound is configured with serve-expired: yes as a default. For someone casually using the docker container, this is not obvious and not mentioned anywhere in the documentation.

May websites work properly with this setting, but IP addresses can get frequently recycled or change. When the old one is no longer valid, weird behavior can occur, for example:

• Weird TLS certificate errors because a new endpoint is being served from the same IP address
• Applications that have strange errors and don't seem to work

And what makes this even weirder to debug is that after serving an expired record, the correct record will update in the background and assuming that it's not cached too long on a browser, the error will disappear.

To Reproduce
To reproduce this, do the following:

1. Set up a DNS record pointing to a valid endpoint with a short TTL
2. After the TTL has expired, change the IP address
3. Try to access the host behind the DNS record, notice that it fails
4. Wait a minute and refresh
5. Find that the host now resolves to the correct record

Expected behavior
This feature should be documented and ideally enabled only behind a flag when the container is started.

If this feature is enabled by default, more guardrails should be enabled, for example, the default for unbound is to serve stale data with no limit: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-serve-expired-ttl

If stale data is served by default, more conservative settings should be used. For example:

serve-expired-ttl defaults to 0, which sets no limit on how long a stale record can sit around before being served
serve-expired-client-timeout is disabled by default, but a reasonable default would be 1800 per the documentation.

Workaround
An easy way to workaround this issue is to copy the unbound configuration from https://github.com/MatthewVance/unbound-docker/blob/master/1.17.1/data/unbound.sh#L41-L363 and then make a new unbound.conf file.

Change the serve-expired: yes option to serve-expired: no

Then when mount this as a volume, similar to the other configuration files, e.g.
--volume=<my-host-path>/unbound.conf:/opt/unbound/etc/unbound/unbound.conf:ro

[MatthewVance]

@billatq those are fair points. I agree the defaults should change. I need to decide if I want to keep serve-expired: yes but tune with more conservative settings or disable it by default.