You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Set up a DNS record pointing to a valid endpoint with a short TTL
After the TTL has expired, change the IP address
Try to access the host behind the DNS record, notice that it fails
Wait a minute and refresh
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 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.
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
The text was updated successfully, but these errors were encountered:
@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.
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:
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:
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 to0
, which sets no limit on how long a stale record can sit around before being servedserve-expired-client-timeout
is disabled by default, but a reasonable default would be1800
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 toserve-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
The text was updated successfully, but these errors were encountered: