Please describe what you are doing to trigger the bug:
I am using the container saspus/duplicacy-web, to backup to backblaze b2 storage for some local files. When this occurs, DNS resolvers such as cloudflare and local routers get thousands of requests from duplicacy, resulting in rate limiting. To be clear, cloudflare responds with the right IP, so the container does not fail or have any issues. When the rate limiting occurs, Duplicacy doesn’t seem to care and just continues backing up.
When I look at the container logs, it is just spammed with [::1]:43040 POST /get_backup_status. A possible clue here is that my network does not support ipv6, so the container never gets a record for ipv6.
The DNS records it appears to be after is as follows:
backblazeb2.com,
backblaze.com
These have various sub-domains, such as api domains and file storage domains, but always get a response with the correct ipv4 address but gets a refused notice for ipv6 records.
Please describe what you expect to happen (but doesn’t):
I expect the container or app to cache the results of DNS and not repeat-ask every second, resulting in excessive load to cloudflare or local dns providers, and eventual rate limiting.
Please describe what actually happens (the wrong behaviour):
The app or container seems to /get_backup_status excessively when backing up to a backblaze storage target. This seems to happen at the same time as the DNS request so I suspect each time this is logged it causes a new DNS request.
A note on how I found this: initially I saw rate limiting errors on my local dns providers, then I switched it over to public ones for just that container, and observed strange failures with cloudflare, realizing I must be getting rate limited by them as well? Either way, I swapped it back to local providers and set a lower client rate limit for this container in particular.
Thanks for your time.